File: node13.html

package info (click to toggle)
kimwitu-doc 10a-3
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k, sarge
  • size: 1,192 kB
  • ctags: 341
  • sloc: makefile: 166; yacc: 125; ansic: 40; lex: 18; sh: 2
file content (251 lines) | stat: -rw-r--r-- 10,945 bytes parent folder | download | duplicates (2)
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
* revised and updated by:  Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
  Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>Unparsing Definitions</TITLE>
<META NAME="description" CONTENT="Unparsing Definitions">
<META NAME="keywords" CONTENT="tpman">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<LINK REL="STYLESHEET" HREF="tpman.css">
<LINK REL="next" HREF="node14.html">
<LINK REL="previous" HREF="node12.html">
<LINK REL="up" HREF="node6.html">
<LINK REL="next" HREF="node14.html">
</HEAD>
<BODY >
<!--Navigation Panel-->
<A NAME="tex2html283"
 HREF="node14.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
 SRC="/usr/share/latex2html/icons/next.png"></A> 
<A NAME="tex2html279"
 HREF="node6.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
 SRC="/usr/share/latex2html/icons/up.png"></A> 
<A NAME="tex2html273"
 HREF="node12.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
 SRC="/usr/share/latex2html/icons/prev.png"></A> 
<A NAME="tex2html281"
 HREF="node4.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents"
 SRC="/usr/share/latex2html/icons/contents.png"></A> 
<A NAME="tex2html282"
 HREF="node58.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index"
 SRC="/usr/share/latex2html/icons/index.png"></A> 
<BR>
<B> Next:</B> <A NAME="tex2html284"
 HREF="node14.html">Including Other Definitions</A>
<B> Up:</B> <A NAME="tex2html280"
 HREF="node6.html">Input</A>
<B> Previous:</B> <A NAME="tex2html274"
 HREF="node12.html">Rewrite Definitions</A>
<BR>
<BR>
<!--End of Navigation Panel-->

<H2><A NAME="SECTION00067000000000000000">&#160;</A>
<A NAME="unp-def">&#160;</A>
<BR>
Unparsing Definitions
</H2>

<P>
Unparsing definitions describe textual representations of terms.
The definitions describe a tree walk over terms by associating <EM>unparsing rules</EM> with
patterns.
For the collection of unparsing definitions <EM>Kimwitu</EM> generates a function
<I>unparse_</I><EM>phylum</EM> for each phylum.
The patterns are the same patterns as can occur in rewrite definitions and with-statements.
An unparsing rule contains a list of unparse <EM>views</EM><A NAME="364">&#160;</A><A NAME="365">&#160;</A> and a list of <EM>unparse items</EM>.
We'll discuss the views later.
An unparse item defines an action for an <I>unparse_</I><EM>phylum</EM> function
and can be any of the following.
<DL>
<DT><STRONG><TT>"a string"</TT></STRONG>
<DD>Each string denotation will be printed as such.
<DT><STRONG><I>{ ...}</I></STRONG>
<DD>Between curly brackets, arbitrary C code can be used,
in which the pattern variables and <I>$0</I> (which is a reference to the entire left hand term) can be used.
This C text is inserted in the unparse function.
The C text can contain curly brackets, nested in matching pairs.
If a non matching bracket needs to be included it can be escaped with a <I>$</I>, e.g. <I>${</I>
and <I>$}</I>.
<DT><STRONG><EM>variable</EM></STRONG>
<DD>An occurrence of a pattern variable is translated into an invocation
of the unparse function for the phylum of the pattern variable.
<DT><STRONG><EM>variable</EM>
<!-- MATH: $\rightarrow$ -->
<IMG
 WIDTH="19" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
 SRC="img2.gif"
 ALT="$\rightarrow$"><EM>attribute</EM></STRONG>
<DD>An occurrence of an attribute is translated
into an invocation
of the unparse function for the phylum or type of the attribute.
An attribute of an attribute is denoted by <EM>variable</EM>
<!-- MATH: $\rightarrow$ -->
<IMG
 WIDTH="19" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
 SRC="img2.gif"
 ALT="$\rightarrow$"><EM>attribute</EM>
<!-- MATH: $\rightarrow$ -->
<IMG
 WIDTH="19" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
 SRC="img2.gif"
 ALT="$\rightarrow$"><EM>attribute</EM> etc.
The unparsing function for a type that is not a phylum has to be provided by the user in
a separate piece of C code.
<DT><STRONG><EM>(typename)variable</EM></STRONG>
<DD>A prefixed cast has the effect that the unparse function
for that type will be called for the variable (or its attribute).
This is useful for the unparsing of non-pattern variables, eg. variables that are defined in
C code.
<DT><STRONG><EM>variable:view</EM></STRONG>
<DD>An appended unparse view name (see below) has the effect that the
unparse function for the variable will be called with this view rather than the current view.
This can also be done with attributes, casted variables and their attributes, and
even strings.
<DT><STRONG><I>${ <EM>unparse items</EM> $}</I></STRONG>
<DD>A list of unparse items enclosed by escaped bracket
is translated into a curly open-bracket followed by the translation of the
<EM>unparse items</EM> followed by a curly close-bracket.
</DL>How an unparse item is actually printed will be discussed later.
First an example, containing strings and pattern variables.<A NAME="378">&#160;</A>
<PRE><HR><!--lgrindfile: unparse_definition_example.k 12:14 Oct 27 1992-->
Plus(e1, e2)              -&gt; [ : e1 <code>"+"</code> e2 ];
Minus(e1, e2)             -&gt; [ : e1 <code>"-"</code> e2 ];
Neg(e1)                   -&gt; [ : <code>"-"</code> e1 ];
Zero()                    -&gt; [ : <code>"0"</code> ];
<BR>
Nilexprlist()             -&gt; [ : ];
Consexprlist(ex, Nilexprlist())-&gt; [ : ex ];
Consexprlist(ex, rest)    -&gt; [ : ex <code>", "</code> rest ];
<HR></PRE> 
In the case of overlapping patterns<A NAME="380">&#160;</A>, the <EM>most</EM> specific match is preferred.
This is used in the example for the introduction of list element separators, see the last line
of the example.
The number of separators is one less than the number of list elements.
For each operator there is always a default pattern, in case none of the patterns match.
The unparsing rule associated with this default pattern unparses all its subphyla.

<P>
The use of the escaped brackets is illustrated in the example below.
<PRE><HR><!--lgrindfile: unparse_escaped_brackets_example.k 14:07 Oct 27 1992-->
Divideby(e1, e2)        -&gt; [ : { <B>if</B> (eq_expr(e2, Zero()) } ${
                                        e1 <code>"/ /* &lt;- division by zero -&gt; */"</code> e2
                                 $} { <B>else</B> } ${
                                        e1 <code>"/"</code> e2
                                 $}
                           ];
<HR></PRE>

<P>
The unparse functions have an additional argument of type <I>uview</I>.
Unparsing rules can be made specific for a set of unparse views by naming these views
between the square open bracket and the colon of an unparsing rule.
For example:
<PRE><HR><!--lgrindfile: unparse_views_example.k 19:57 Oct 21 1992-->
Plus(e1 e2)     -&gt; [ view1 view2: e1 <code>"+"</code> e2 ];
<HR></PRE>

An omitted view list defaults to all unparse views.
This is equivalent to a view list that only contains the view name <I>base_uview</I>.
The type <I>uview</I> is an enumeration type of all view names occurring in the unparsing rules.
It always contains the view name <I>base_uview</I>.

<P>
Views can be declared as in the following example:<A NAME="388">&#160;</A><A NAME="389">&#160;</A>
<PRE><HR><!--lgrindfile: unparse_view_declaration_example.k 14:04 Feb 19 1997-->
%uview view1 view2; <I>/* the `%' is part of the keyword */</I>
<HR></PRE>

Unparse views should be declared.
If the termprocessor input contains one or more unparse view declarations it
will report errors for all unparse views that are used and not declared.
The use of view declarations may help to find typing errors in view names -
in term processor input that does not contain view declarations, the misspelling
of a view name may just introduce a new view (with the misspelled name).

<P>
If several unparse rules share the same left-hand side,
they may be combined by grouping the right-hand sides
(with seperating commas).
If several unparse rules share the same right-hand side,
they may be combined by grouping the left-hand sides
(with seperating commas).
The general form of an unparse rule is shown below:
<PRE><HR><!--lgrindfile: unparse_rule_general.k 12:33 Feb 19 1997-->
pattern1, pattern2, ... -&gt; [ v1 v2 ... : ... ], ..., [ vn ... : ... ] ;
<HR></PRE>

<P>
The <I>unparse_</I><EM>phylum</EM> functions that are generated have three arguments:
the term to be unparsed, a (<I>void</I>) function, the <EM>printer</EM>, to be applied to each string
(including string denotations of the predefined phyla) and an
argument of type <I>uview</I>, which is passed to the printer function.
The C code in the unparsing rules can refer to the latter two arguments directly by the names
<I>kc_printer</I>  and <I>kc_current_view</I> respectively.
The user provides the printer function.
The simplest example of such a function and its use is as follows.
<A NAME="399">&#160;</A><A NAME="400">&#160;</A>
<PRE><HR><!--lgrindfile: printer_function_example.k 14:03 Feb 19 1997-->
<B>void</B> printer(<B>char</B> *s, uview v) {
    printf(<code>"%s"</code>, s);
}
<BR>
{ <I>/* example of usage */</I>
    unparse_exprlist(expression, printer, base_uview);
}
<HR></PRE>

<P>
There are two features that are notably missing from unparsing rules.
A feature for handling list element separators is not necessary, as is shown above.
A feature for specifying indentation in the output can be emulated in the printer function.
How to do that is explained in Section&nbsp;<A HREF="node30.html#cook-unp">4.2</A>.

<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html283"
 HREF="node14.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
 SRC="/usr/share/latex2html/icons/next.png"></A> 
<A NAME="tex2html279"
 HREF="node6.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
 SRC="/usr/share/latex2html/icons/up.png"></A> 
<A NAME="tex2html273"
 HREF="node12.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
 SRC="/usr/share/latex2html/icons/prev.png"></A> 
<A NAME="tex2html281"
 HREF="node4.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents"
 SRC="/usr/share/latex2html/icons/contents.png"></A> 
<A NAME="tex2html282"
 HREF="node58.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index"
 SRC="/usr/share/latex2html/icons/index.png"></A> 
<BR>
<B> Next:</B> <A NAME="tex2html284"
 HREF="node14.html">Including Other Definitions</A>
<B> Up:</B> <A NAME="tex2html280"
 HREF="node6.html">Input</A>
<B> Previous:</B> <A NAME="tex2html274"
 HREF="node12.html">Rewrite Definitions</A>
<!--End of Navigation Panel-->
<ADDRESS>
<I></I>
<BR><I>2000-04-17</I>
</ADDRESS>
</BODY>
</HTML>