File: pp_2.html

package info (click to toggle)
eli-doc 4.4.0-4
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 13,256 kB
  • ctags: 4,583
  • sloc: makefile: 42
file content (457 lines) | stat: -rw-r--r-- 20,397 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.29
     from ../tnf/pp.tnf on 12 Febuary 2003 -->

<TITLE>Products and Parameters Reference - Generating Specifications</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF0000" BACKGROUND="gifs/bg.gif">
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0" VALIGN=BOTTOM>
<TR VALIGN=BOTTOM>
<TD WIDTH="160" VALIGN=BOTTOM><IMG SRC="gifs/elilogo.gif" BORDER=0>&nbsp;</TD>
<TD WIDTH="25" VALIGN=BOTTOM><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>
<TD ALIGN=LEFT WIDTH="600" VALIGN=BOTTOM><IMG SRC="gifs/title.gif"></TD>
</TR>
</TABLE>

<HR size=1 noshade width=785 align=left>
<TABLE BORDER=0 CELLSPACING=2 CELLPADDING=0>
<TR>
<TD VALIGN=TOP WIDTH="160">
<h4>General Information</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="index.html">Eli: Translator Construction Made Easy</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gindex_toc.html">Global Index</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="faq_toc.html" >Frequently Asked Questions</a> </td></tr>
</table>

<h4>Tutorials</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="EliRefCard_toc.html">Quick Reference Card</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="novice_toc.html">Guide For new Eli Users</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="news_toc.html">Release Notes of Eli</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="nametutorial_toc.html">Tutorial on Name Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="typetutorial_toc.html">Tutorial on Type Analysis</a></td></tr>
</table>

<h4>Reference Manuals</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ui_toc.html">User Interface</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="pp_toc.html">Eli products and parameters</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lidoref_toc.html">LIDO Reference Manual</a></td></tr>
</table>

<h4>Libraries</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lib_toc.html">Eli library routines</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="modlib_toc.html">Specification Module Library</a></td></tr>
</table>

<h4>Translation Tasks</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lex_toc.html">Lexical analysis specification</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="syntax_toc.html">Syntactic Analysis Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="comptrees_toc.html">Computation in Trees</a></td></tr>
</table>

<h4>Tools</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lcl_toc.html">LIGA Control Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="show_toc.html">Debugging Information for LIDO</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gorto_toc.html">Graphical ORder TOol</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="fw_toc.html">FunnelWeb User's Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ptg_toc.html">Pattern-based Text Generator</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="deftbl_toc.html">Property Definition Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="oil_toc.html">Operator Identification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="tp_toc.html">Tree Grammar Specification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="clp_toc.html">Command Line Processing</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="cola_toc.html">COLA Options Reference Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="idem_toc.html">Generating Unparsing Code</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="mon_toc.html">Monitoring a Processor's Execution</a> </td></tr>
</table>

<h4>Administration</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="sysadmin_toc.html">System Administration Guide</a> </td></tr>
</table>

<HR WIDTH="100%">
<CENTER>&nbsp;<A HREF="mailto:elibugs@cs.colorado.edu"><IMG SRC="gifs/button_mail.gif" NOSAVE BORDER=0 HEIGHT=32 WIDTH=32></A><A HREF="mailto:elibugs@cs.colorado.edu">Questions, Comments, ....</A></CENTER>

</TD>
<TD VALIGN=TOP WIDTH="25"><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>

<TD VALIGN=TOP WIDTH="600">
<H1>Products and Parameters Reference</H1>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_1.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_3.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
<H1><A NAME="SEC10" HREF="pp_toc.html#SEC10">Generating Specifications</A></H1>
<P>
Sometimes a common problem can be solved by a collection of specifications
having a particular structure.
These specifications themselves can be generated, given simpler
specifications.
The products and parameters described in this chapter are most often used
in requests that appear in type-<CODE>specs</CODE> files.
They result in specifications that are then used to describe the complete
processor.
<P>
<H2><A NAME="SEC11" HREF="pp_toc.html#SEC11">consyntax -- Concrete Syntax</A></H2>
<P>
<A NAME="IDX33"></A>
<PRE>
:consyntax
</PRE>
<P>
Requesting <CODE>:consyntax</CODE> will result in a type-<TT>`con'</TT> file
containing the complete concrete syntax.  This includes all concrete
syntax rules provided by the user in type-<TT>`con'</TT> files (translated
into strict BNF form) as well as rules added to the concrete
syntax as a result of the mapping process
(see  <A HREF="syntax_2.html#SEC8">Mapping of Syntactic Analysis</A>).
<P>
<H2><A NAME="SEC12" HREF="pp_toc.html#SEC12">abstree -- Abstract Tree Grammar</A></H2>
<P>
<A NAME="IDX34"></A>
<PRE>
:abstree
</PRE>
<P>
Requesting <CODE>:abstree</CODE> will result in a type-<TT>`lido'</TT> file
containing the complete abstract tree grammar.
This consists of all rules supplied by the user in
type-<CODE>lido</CODE> files, plus any additional rules derived from rules
appearing only in type-<CODE>con</CODE> files in the syntax mapping process
(see  <A HREF="syntax_2.html#SEC8">Mapping of Syntactic Analysis</A>).
<P>
<H2><A NAME="SEC13" HREF="pp_toc.html#SEC13">absyntax -- Abstract Syntax</A></H2>
<P>
<A NAME="IDX35"></A>
<PRE>
:absyntax
</PRE>
<P>
Requesting <CODE>:absyntax</CODE> will result in a type-<CODE>lido</CODE> file
containing the complete abstract syntax.
This derivation differs from the <CODE>:abstree</CODE> derivation
(see  <A HREF="pp_2.html#SEC12">abstree -- Abstract Tree Grammar</A>) in that rules which can only be derived
for computed subtrees
(see  <A HREF="lidoref_10.html#SEC18">Computed Subtrees of LIDO - Reference Manual</A>)
are not included.
<P>
<H2><A NAME="SEC14" HREF="pp_toc.html#SEC14">pgram -- Parsing Grammar</A></H2>
<P>
<A NAME="IDX36"></A>
<PRE>
:pgram
</PRE>
<P>
The parsing grammar requested by the <CODE>:pgram</CODE> derivation is the
input to the parser generator.  This includes the integer encodings of the
terminal symbols, any directives supplied by the user to direct
the automatic error correction of the parser, and each of the BNF rules
in the concrete syntax with associated actions.  These actions include
actions supplied by the user as well as actions generated to construct
an abstract syntax tree.
<P>
Note that the mapping process may cause the injection of certain chain
rules due to <CODE>BOTTOMUP</CODE> constraints specified in the attribute
<A NAME="IDX37"></A>
grammar.  These injected rules do not appear in the result of the
<CODE>:consyntax</CODE> derivation, which makes <CODE>:pgram</CODE> the most appropriate
derivation to consult when trying to resolve parsing conflicts which may
have resulted from the injection of these chain rules.
See  <A HREF="syntax_2.html#SEC18">BOTTOMUP of Syntactic Analysis</A>.
<P>
<H2><A NAME="SEC15" HREF="pp_toc.html#SEC15">kwd -- Recognize Specified Literals as Identifiers</A></H2>
<P>
<A NAME="IDX38"></A>
<PRE>
<VAR>file</VAR>.gla :kwd
</PRE>
<P>
Specifications that force literals whose lexical structure is defined by
<CODE><VAR>file</VAR>.gla</CODE> to be handled specially by the generated scanner.
<A NAME="IDX39"></A>
<P>
Normally, each literal found in the context-free grammar is recognized
explicitly by the scanner as the specified character sequence.
This is in contrast to identifiers, denotations and comments,
whose lexical structures are defined by regular expressions.
The literals are defined by their appearance in the grammar, and no
type-<CODE>gla</CODE> file describes their structure.
<P>
The <CODE>:kwd</CODE> product is used when literals are representative of the
character strings
<A NAME="IDX40"></A>
that should appear in the program, but not necessarily identical to them.
The classic case in which <CODE>:kwd</CODE> would be used (and from which its
name is derived) is the recognition of mixed-case keywords.
<A NAME="IDX41"></A>
A literal <CODE>'if'</CODE> appearing in a Pascal grammar is representative of
the character strings <CODE>if</CODE>, <CODE>If</CODE>, <CODE>iF</CODE> and <CODE>IF</CODE> but is
identical to only the first.
Whenever any one of these four character strings appears in a Pascal
program, it should be recognized by the scanner as an instance of the
literal <CODE>'if'</CODE>.
All Pascal keywords behave in this fashion, and each has the form of an
identifier.
<P>
Suppose that file <CODE>pkeys.gla</CODE> defines the structure of the literals
used in the grammar, and the following line were added to one of the
type-<CODE>.specs</CODE> files for a Pascal compiler:
<P>
<PRE>
pkeys.gla :kwd
</PRE>
<P>
This would prevent the scanner of the generated compiler from recognizing
Pascal keywords explicitly as the character sequences specified
by the literals given in the grammar.
Other literals (such as <CODE>:=</CODE>), which did not fit the definition given
by <CODE>pkeys.gla</CODE>, would still be recognized by the scanner as the
specified character sequences.
<P>
It is important to remember that the type-<TT>`gla'</TT> file to which the
<CODE>kwd</CODE> derivation is applied defines the form of the literals <EM>in
the grammar</EM>, not in the input text.
<P>
<H2><A NAME="SEC16" HREF="pp_toc.html#SEC16">inst -- Instantiate a Generic Module</A></H2>
<P>
<A NAME="IDX42"></A>
<PRE>
<VAR>file</VAR>.gnrc :inst
</PRE>
<P>
A specification consisting of one or more files is generated from
<CODE><VAR>file</VAR>.gnrc</CODE>.
<A NAME="IDX43"></A>
This product is normally used to instantiate the common problem solutions
that have been stored in the library
<A NAME="IDX44"></A>
(see  <A HREF="modlib_2.html#SEC2">Module Instantiation of Specification Module Library</A>):
<P>
<PRE>
$elipkg/Name/AlgScope.gnrc :inst
</PRE>
<P>
Here the path <TT>`$elipkg/Name'</TT> accesses the portion of the library
devoted to problems arising in the context of name analysis
<A NAME="IDX45"></A>
(see  <A HREF="name_toc.html">Name Analysis Library of Specification Module Library: Name Analysis</A>).
<P>
Type-<CODE>gnrc</CODE> files can be supplied by a user.
<A NAME="IDX46"></A>
They are simply shell scripts that carry out whatever
actions are needed to instantiate a generic specification.
Thus a user of Eli can construct generic specifications
<A NAME="IDX48"></A>
<A NAME="IDX47"></A>
appropriate to a specific domain
<A NAME="IDX49"></A>
and use them exactly like library specifications.
<P>
Scripts appearing as type-<CODE>gnrc</CODE> files are invoked
<A NAME="IDX51"></A>
<A NAME="IDX50"></A>
with up to three parameters.
The first parameter is the <CODE>sed</CODE>(1) program,
the second parameter is the string specified by <CODE>+instance</CODE>,
and the third parameter is the string specified by <CODE>+referto</CODE>.
When the script is invoked, its full path name is used.
Therefore the script can determine the directory in which it is stored,
and access specific files in that directory.
<P>
Here is an example of a type-<CODE>gnrc</CODE> file,
<TT>`$elipkg/Name/AlgScope.gnrc'</TT>:
<P>
<PRE>
#!/bin/sh
# $Id: pp.tnf,v 2.11 2000/05/05 09:58:42 mjung Exp $
# Copyright, 1994, AG-Kastens, University Of Paderborn

moddir=`expr $0 : '\(.*\)/.*' \| '.'`

$1 -e "s/|NAME|/$2/g
s/|KEY|/$3/g" "$moddir"/AlgScope.fw &#62; "$2"AlgScope.fw
</PRE>
<P>
It first sets <CODE>moddir</CODE> to the name of the directory in which it resides,
then uses <CODE>sed</CODE> to modify file <TT>`AlgScope.fw'</TT> in that directory.
The script replaces the string <CODE>|NAME|</CODE> with the string specified by the
<CODE>+instance</CODE> parameter of the original request.
(If no <CODE>+instance</CODE> parameter was supplied, <CODE>$1</CODE> is empty and
every occurrence of the string <CODE>|NAME|</CODE> is simply deleted.)
Similarly, it either replaces the string <CODE>|KEY|</CODE> with the string
specified by the <CODE>+referto</CODE> parameter or deletes it.
Finally, the name of the output file depends on the
<CODE>+instance</CODE> parameter of the original request.
<P>
The output file will become part of the specification that contained the
<CODE>:inst</CODE> request.
<P>
<H2><A NAME="SEC17" HREF="pp_toc.html#SEC17">ExpInfo -- Information about remote attribute access</A></H2>
<P>
<A NAME="IDX52"></A>
<PRE>
:ExpInfo
</PRE>
<P>
Obtain information about the processing of LIDO specifications,
especially
information concerning the expansion of remote attribute accesses
(i. e. INCLUDING, CONSTITUENTS, and CHAIN). The generated listing
describes how each remote access construct can be replaced by a
set of equivalent computations propagating the accessed values through
adjacent contexts. This file is useful if special difficult cases
regarding problems with remote dependences arise.
<P>
Additional information about attribute dependences and attribute
storage optimization can be obtained by adding the parameters <CODE>+OrdI</CODE> and
<CODE>+OptimI</CODE>. 
<P>
<PRE>
Example: foo.specs+OrdI:ExpInfo&#62;
</PRE>
<P>
For a more detailed description of Liga's protocol options
and more advanced options, see 
 <A HREF="lcl_toc.html">Liga Control Language Manual of Liga Control Language Manual</A>.
<P>
<H2><A NAME="SEC18" HREF="pp_toc.html#SEC18">OrdInfo -- Information about attribute dependence</A></H2>
<P>
<A NAME="IDX53"></A>
<PRE>
:OrdInfo
</PRE>
<P>
Obtain information about the processing of LIDO specifications,
especially
information concerning the attribute dependences.
The protocol provides for each grammar rule the set of direct 
dependences between attributes occurring in this rule.
<P>
Additional information about remote attribute access and attribute
storage optimization can be obtained by adding the parameters 
<CODE>+ExpI</CODE> and
<CODE>+OptimI</CODE>. 
<P>
<PRE>
Example: foo.specs+ExpI:OrdInfo&#62;
</PRE>
<P>
For a more detailed description of Liga's protocol options
and more advanced options, see 
 <A HREF="lcl_toc.html">Liga Control Language Manual of Liga Control Language Manual</A>.
<P>
<H2><A NAME="SEC19" HREF="pp_toc.html#SEC19">OptimInfo -- Information about attribute storage optimization</A></H2>
<P>
<A NAME="IDX54"></A>
<PRE>
:OptimInfo
</PRE>
<P>
Obtain information about the processing of LIDO specifications,
especially
information on attribute storage optimization.
For each attribute this protocol provides information where this
attribute is stored. Possible storage locations are "tree node",
"global variable" and "global stack".
<P>
Additional information about remote attribute access and attribute
dependences can be obtained by adding the parameters <CODE>+ExpI</CODE> and
<CODE>+OrdI</CODE>. 
<P>
<PRE>
Example: foo.specs+ExpI:OptimInfo&#62;
</PRE>
<P>
For a more detailed description of Liga's protocol options
and more advanced options, see 
 <A HREF="lcl_toc.html">Liga Control Language Manual of Liga Control Language Manual</A>.
<P>
<H2><A NAME="SEC20" HREF="pp_toc.html#SEC20">show -- LIDO Table Viewers showFe and showMe</A></H2>
<P>
<A NAME="IDX55"></A>
<PRE>
:showFe
<A NAME="IDX56"></A>:showMe
</PRE>
<P>
Obtain a list of files that contain internal representations of LIDO text
translated into readable text. <CODE>:showFe</CODE> shows LIDO text after
the processing by the frontend of the Liga-System, <CODE>:showMe</CODE> shows
the same information after attribute evaluator construction.
<P>
These informations can be useful for debugging a LIDO-Specification or
to understand LIGA-Processing in more depth.
<P>
See  <A HREF="show_toc.html">Overview of SHOW - Debugging Information for LIDO</A>, for more details.
<P>
<H2><A NAME="SEC21" HREF="pp_toc.html#SEC21">instance -- Name an Instance of a Generic Module</A></H2>
<P>
<A NAME="IDX57"></A>
<PRE>
+instance='<VAR>string</VAR>'
</PRE>
<P>
Use <VAR>string</VAR> to name the instance generated by the request.
<A NAME="IDX59"></A>
<A NAME="IDX58"></A>
No spaces are allowed within the <VAR>string</VAR>, and characters meaningful to
the shell that interprets the associated type-<CODE>gnrc</CODE> file may cause
problems.
<P>
Not all generic modules allow distinct instances to be created.
See the documentation of each such module for the precise effect of
<CODE>+instance</CODE>.
<P>
<H2><A NAME="SEC22" HREF="pp_toc.html#SEC22">referto -- Relate Instances of Generic Modules</A></H2>
<P>
<A NAME="IDX60"></A>
<PRE>
+referto='<VAR>string</VAR>'
</PRE>
<P>
Use <VAR>string</VAR> to relate the current instance of a generic module to some
specific instance of another generic module.
<P>
Not all generic modules allow relationships to be specified.
See the documentation of each such module for the precise effect of
<CODE>+referto</CODE>.
<P>
<HR size=1 noshade width=600 align=left>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_1.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_3.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="pp_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
</TD>
</TR>
</TABLE>

</BODY></HTML>