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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>gp2c types and the description system
</TITLE>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.10">
<STYLE type="text/css">
.li-itemize{margin:1ex 0ex;}
.li-enumerate{margin:1ex 0ex;}
.dd-description{margin:0ex 0ex 1ex 4ex;}
.dt-description{margin:0ex;}
.toc{list-style:none;}
.thefootnotes{text-align:left;margin:0ex;}
.dt-thefootnotes{margin:0em;}
.dd-thefootnotes{margin:0em 0em 0em 2em;}
.footnoterule{margin:1em auto 1em 0px;width:50%;}
.caption{padding-left:2ex; padding-right:2ex; margin-left:auto; margin-right:auto}
.title{margin:2ex auto;text-align:center}
.center{text-align:center;margin-left:auto;margin-right:auto;}
.flushleft{text-align:left;margin-left:0ex;margin-right:auto;}
.flushright{text-align:right;margin-left:auto;margin-right:0ex;}
DIV TABLE{margin-left:inherit;margin-right:inherit;}
PRE{text-align:left;margin-left:0ex;margin-right:auto;}
BLOCKQUOTE{margin-left:4ex;margin-right:4ex;text-align:left;}
TD P{margin:0px;}
.boxed{border:1px solid black}
.textboxed{border:1px solid black}
.vbar{border:none;width:2px;background-color:black;}
.hbar{border:none;height:2px;width:100%;background-color:black;}
.hfill{border:none;height:1px;width:200%;background-color:black;}
.vdisplay{border-collapse:separate;border-spacing:2px;width:auto; empty-cells:show; border:2px solid red;}
.vdcell{white-space:nowrap;padding:0px;width:auto; border:2px solid green;}
.display{border-collapse:separate;border-spacing:2px;width:auto; border:none;}
.dcell{white-space:nowrap;padding:0px;width:auto; border:none;}
.dcenter{margin:0ex auto;}
.vdcenter{border:solid #FF8000 2px; margin:0ex auto;}
.minipage{text-align:left; margin-left:0em; margin-right:auto;}
.marginpar{border:solid thin black; width:20%; text-align:left;}
.marginparleft{float:left; margin-left:0ex; margin-right:1ex;}
.marginparright{float:right; margin-left:1ex; margin-right:0ex;}
.theorem{text-align:left;margin:1ex auto 1ex 0ex;}
.part{margin:2ex auto;text-align:center}
</STYLE>
</HEAD>
<BODY >
<!--HEVEA command line is: /usr/bin/hevea -fix ./type.tex -->
<!--CUT DEF section 1 --><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain"><TT>gp2c</TT> types and the description system</H1><H3 CLASS="titlerest">By Bill Allombert</H3></TD></TR>
</TABLE><!--TOC section Contents-->
<H2 CLASS="section"><!--SEC ANCHOR -->Contents</H2><!--SEC END --><UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc1">1<TT>gp2c</TT> types</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc2">1.1Introduction</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc3">1.2List of types</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc4">1.2.1Basic types</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc5">1.2.2Special types</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc6">1.2.3Internal types</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc7">1.2.4Types for data structure.</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc8">1.3C-Type</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc9">2The description system</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc10">2.1Introduction</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc11">2.2Definitions</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc12">2.2.1Description</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc13">2.2.2Rule</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc14">2.2.3Pattern</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc15">2.2.4Type</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc16">2.2.5Modelist</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc17">2.2.6Action</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc18">2.3Pattern atom</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc19">2.4Matching</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc20">2.5Mode</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc21">2.6Lists of replacement strings</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc22">2.7Lists of RPN commands</A>
</LI></UL>
</LI></UL><!--TOC section <TT>gp2c</TT> types-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc1">1</A><TT>gp2c</TT> types</H2><!--SEC END --><!--TOC subsection Introduction-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc2">1.1</A>Introduction</H3><!--SEC END --><P>The main feature GP2C adds above GP is the use of types. Types give a
semantic to PARI objects, so that GP2C can generate code that use
specialized (hence faster) PARI functions instead of generic ones. Please
read the section ’Advanced use of GP2C’ in the GP2C manual for how to use
the GP2C types and examples.</P><P>Such types are used in conjunctions with so-called <EM>descriptions</EM> which
are stored in the field ’Description:’ of the file <TT>pari.desc</TT> and provide
the actual C code to use depending of the types of the arguments. They are
described in Section<A HREF="#description">2</A>.</P><P>Abstractly, a GP2C type is a set of pairs (<I>A</I>,<I>B</I>) where <I>A</I> is a mathematical
object and <I>B</I> its computer representation. Two different types can contain
the same mathematical object, with a different computer representation.
For example the type <I>bool</I> is the set {(true,1L), (false,0L)},
<EM>i.e.</EM>true and false with true coded by the C-long integer 1 and
false coded by the C-long integer 0; the type <I>negbool</I> is
the set {(true,0L), (false,1L)} which is the same set of mathematical objects,
but now true is coded by the C-long integer 0 and false by the C-long
integer 1.</P><P>For each GP2C type, there exists a C type <I>Ct</I> such that for all pairs (<I>A</I>,<I>B</I>)
belonging to the type, the C type of <I>B</I> is <I>Ct</I>. This C type is specified by
the description <FONT COLOR=purple>_typedef</FONT>.</P><P>The GP2C types are preordered. Abstractly, we say that <I>t</I><SUB>1</SUB>≺
<I>t</I><SUB>2</SUB> if and only if there is a map <I>f</I> such that (<I>A</I>,<I>B</I>)↦ (<I>A</I>,<I>f</I>(<I>B</I>))
defines a one-to-one mapping from <I>t</I><SUB>1</SUB> to <I>t</I><SUB>2</SUB>.
Practically we restrict the relation ≺ to make it a partial order
such that any two types have an upper bound.
This partial order is defined by the chains in the description
<FONT COLOR=purple>_type_preorder</FONT>. It can be printed by running <CODE>gp2c -t</CODE>.</P><BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<DIV CLASS="center">
<TABLE CLASS="display dcenter"><TR VALIGN="middle"><TD CLASS="dcell">
<IMG SRC="type001.png">
</TD></TR>
</TABLE>
<DIV CLASS="caption"><TABLE CELLSPACING=6 CELLPADDING=0><TR><TD VALIGN=top ALIGN=left>Figure 1: Example of type preorder</TD></TR>
</TABLE></DIV>
<A NAME="fig:type"></A>
</DIV>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></BLOCKQUOTE><P>The process of converting a mathematical object from one type to
another is called casting. The casting methods known to GP2C are
given by the <FONT COLOR=purple>_cast</FONT> description.</P><!--TOC subsection List of types-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc3">1.2</A>List of types</H3><!--SEC END --><P>In this section, we list the types known to PARI/GP.
The current list is available in the description <FONT COLOR=purple>_typedef</FONT>.</P><!--TOC subsubsection Basic types-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc4">1.2.1</A>Basic types</H4><!--SEC END --><DL CLASS="description"><DT CLASS="dt-description">
<B>small</B></DT><DD CLASS="dd-description"> Small integers represented by C <FONT COLOR=purple>long</FONT> integers.
</DD><DT CLASS="dt-description"><B>int</B></DT><DD CLASS="dd-description"> Multi-precision integers represented by <TT>t_INT</TT> GENs.
</DD><DT CLASS="dt-description"><B>real</B></DT><DD CLASS="dd-description"> Multi-precision floating point real numbers represented by <TT>t_REAL</TT> GENs.
</DD><DT CLASS="dt-description"><B>mp</B></DT><DD CLASS="dd-description"> Multi-precision numbers. Union of the types <I>int</I> and <I>real</I>.
</DD><DT CLASS="dt-description"><B>vecsmall</B></DT><DD CLASS="dd-description"> Vectors of small integers represented by <TT>t_VECSMALL</TT> GENs.
</DD><DT CLASS="dt-description"><B>vec</B></DT><DD CLASS="dd-description"> Vectors and matrices of PARI objects, represented by <TT>t_VEC</TT>,
<TT>t_COL</TT> or <TT>t_MAT</TT> GENs.
</DD><DT CLASS="dt-description"><B>var</B></DT><DD CLASS="dd-description"> Polynomial variables represented by their variable number which is
a C <FONT COLOR=purple>long</FONT> integer. This is associated to the prototype code ’n’.
</DD><DT CLASS="dt-description"><B>pol</B></DT><DD CLASS="dd-description"> Polynomials represented by <TT>t_POL</TT> GENs.
</DD><DT CLASS="dt-description"><B>genstr</B></DT><DD CLASS="dd-description"> Strings represented by <TT>t_STR</TT> GENs.
</DD><DT CLASS="dt-description"><B>list</B></DT><DD CLASS="dd-description"> GP lists represented by <TT>t_LIST</TT> GENs.
</DD><DT CLASS="dt-description"><B>gen</B></DT><DD CLASS="dd-description"> Generic PARI objects represented by GENs.
</DD></DL><!--TOC subsubsection Special types-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc5">1.2.2</A>Special types</H4><!--SEC END --><DL CLASS="description"><DT CLASS="dt-description">
<B>void</B></DT><DD CLASS="dd-description"> This type is a set with only one element called <I>void</I>. This is
the return type of functions not returning anything. GP allows to cast it to
0.
</DD><DT CLASS="dt-description"><B>bool</B></DT><DD CLASS="dd-description"> Boolean values represented as C <FONT COLOR=purple>long</FONT> integers, where 1 is
true and 0 is false.
</DD><DT CLASS="dt-description"><B>negbool</B></DT><DD CLASS="dd-description"> Negated boolean values represented as C <FONT COLOR=purple>long</FONT> integers,
where 0 is true and 1 is false.</DD><DT CLASS="dt-description"><B>lg</B></DT><DD CLASS="dd-description"> Vector lengths represented by the <FONT COLOR=purple>lg</FONT> macro output, i.e.
a C <FONT COLOR=purple>long</FONT> integer equal to the actual length plus one.</DD><DT CLASS="dt-description"><B>str</B></DT><DD CLASS="dd-description"> C strings represented by C <FONT COLOR=purple>const char *</FONT> strings.
</DD><DT CLASS="dt-description"><B>typ</B></DT><DD CLASS="dd-description"> GEN types represented by C <FONT COLOR=purple>long</FONT> integers, as returned by the
<FONT COLOR=purple>typ()</FONT> macro.
</DD></DL><!--TOC subsubsection Internal types-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc6">1.2.3</A>Internal types</H4><!--SEC END --><P>
The following types are mainly for internal use inside GP2C.
</P><DL CLASS="description"><DT CLASS="dt-description">
<B>empty</B></DT><DD CLASS="dd-description"> This type is the empty set. No individual object can be of this
type but a set of objects can. In fact this is a default type for an
unspecified set of objects.
</DD><DT CLASS="dt-description"><B>small_int</B></DT><DD CLASS="dd-description"> Small integers represented by C <FONT COLOR=purple>int</FONT> integers.
This is only available for compatibility with PARI function returning
<FONT COLOR=purple>int</FONT> (instead of <FONT COLOR=purple>long</FONT>).
</DD><DT CLASS="dt-description"><B>bptr</B></DT><DD CLASS="dd-description"> Byte pointer. This is used for the <FONT COLOR=purple>primepointer</FONT> global
variable.
</DD><DT CLASS="dt-description"><B>func_GG</B></DT><DD CLASS="dd-description"> function with protype <FONT COLOR=purple>GEN f(GEN,GEN)</FONT>. Used by
<I>forvec</I>.
</DD><DT CLASS="dt-description"><B>pari_sp</B></DT><DD CLASS="dd-description"> This is the stack pointer type <FONT COLOR=purple>pari_sp</FONT>.
</DD></DL><!--TOC subsubsection Types for data structure.-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc7">1.2.4</A>Types for data structure.</H4><!--SEC END --><P>
These types are mainly defined to allow the use of inline member functions.</P><DL CLASS="description"><DT CLASS="dt-description">
<B>nf</B></DT><DD CLASS="dd-description"> Number field as returned by <I>nfinit</I>.
</DD><DT CLASS="dt-description"><B>bnf</B></DT><DD CLASS="dd-description"> Big number field as returned by <I>bnfinit</I>.
</DD><DT CLASS="dt-description"><B>bnr</B></DT><DD CLASS="dd-description"> Ray class field as returned by <I>bnrinit</I>.
</DD><DT CLASS="dt-description"><B>ell</B></DT><DD CLASS="dd-description"> Elliptic curve as returned by <I>ellinit</I>.
</DD><DT CLASS="dt-description"><B>bell</B></DT><DD CLASS="dd-description"> Big elliptic curve as returned by <I>ellinit</I>.
</DD><DT CLASS="dt-description"><B>clgp</B></DT><DD CLASS="dd-description"> Class group as returned by the ’clgp’ member function.
</DD><DT CLASS="dt-description"><B>prid</B></DT><DD CLASS="dd-description"> Prime ideal as returned by <I>idealprimedec</I>.
</DD><DT CLASS="dt-description"><B>gal</B></DT><DD CLASS="dd-description"> Galois group as returned by <I>galoisinit</I>.
</DD></DL><!--TOC subsection C-Type-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc8">1.3</A>C-Type</H3><!--SEC END --><P>
A <I>C-Type</I> is just a level of indirection toward real C types.
C-types are defined by the descriptions <FONT COLOR=purple>_decl_base</FONT> and
<FONT COLOR=purple>_decl_ext</FONT>. Each type belongs to a C-type as specified by the
description <FONT COLOR=purple>_typedef</FONT>.</P><!--TOC section The description system-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc9">2</A>The description system</H2><!--SEC END --><P><A NAME="description"></A></P><!--TOC subsection Introduction-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc10">2.1</A>Introduction</H3><!--SEC END --><P>The description system is a way to describe the PARI application programming
interface in a way understandable by both the GP2C compiler and human
beings. The present document is mostly addressed to this second category.
We start by a simple example:</P><P>The description of the GP function <I>sqr</I> is
</P><PRE CLASS="verbatim"> (int):int sqri($1)
(mp):mp gsqr($1)
(gen):gen gsqr($1)
</PRE><P>Each line is called a <I>rule</I>, which in this case consists of three
parts. Let us consider the first one: the parts <CODE>(int)</CODE>, <CODE>:int</CODE> and
<CODE>sqri($1)</CODE> are respectively called the <I>pattern</I>, <I>type</I>,
and <I>action</I> part.</P><P>When GP2C compiles <I>sqr(1)</I>, it computes the types of the arguments
(here<I>1</I> is of type <I>small</I>) and matches them against the patterns
from top to bottom. The “best” rule is used; in case of a tie, the topmost
rule wins. Here, all three rules apply, and the first rule wins. Since the type
of this rule is <I>int</I>, GP2C sets the type of the expression
<I>sqr(1)</I> to <I>int</I>. The action part is <CODE>sqri($1)</CODE>, so GP2C
generates the C code <FONT COLOR=purple>sqri($1)</FONT> where <FONT COLOR=purple>$1</FONT> is replaced by the
code of the argument <I>1</I> cast to the pattern type (<I>int</I>). The result
is the C code <FONT COLOR=purple>sqri(gen_1)</FONT>.</P><P>Now a more complex example: the description of the GP function <I>exp</I> is
</P><PRE CLASS="verbatim"> (real):real mpexp($1)
(mp):mp:prec gexp($1, prec)
(gen):gen:prec gexp($1, prec)
</PRE><P>When GP2C compiles <I>exp(1)</I>, it looks for the "best" rules.
The first rule cannot be used, because there is no way to cast a
<I>small</I> to a <I>real</I>, so it uses the second rule.
This time the result will be
of type <I>mp</I>. The extra part <CODE>:prec</CODE> is called a mode. The
mode ‘prec’ states that the action part will use the special ‘prec’
variable that holds the current real precision. This is obvious from
the action part code, but GP2C do not parse the action part so it
needs this mode. Note that the last rule is also valid and has the
same action part so would generate the exact same code. However, the
type of the expression would be less precise.</P><P>The description of the GP function <I>matdet</I> is
</P><PRE CLASS="verbatim"> (gen, ?0):gen det($1)
(gen, 1):gen det2($1)
(gen, #small):gen $"incorrect flag in matdet"
(gen, small):gen det0($1, $2)
</PRE><P>We see several new pattern atoms:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
<I>1</I> matches a literal 1, e.g. <I>matdet(M,1)</I> would match the
second rule.
</LI><LI CLASS="li-itemize"><I>?0</I> matches an optional literal 0: <I>matdet(M)</I>,
<I>matdet(M,0)</I> and <I>matdet(M,)</I> all match the first rule.
</LI><LI CLASS="li-itemize"><I>#small</I> matches an unspecified literal <I>small</I>.
</LI></UL><P>
Finally, we also see a new action <I>$"…"</I>, which causes GP2C
to display the error message and abort.</P><!--TOC subsection Definitions-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc11">2.2</A>Definitions</H3><!--SEC END --><P>
We now give a formal definition of descriptions.
</P><!--TOC subsubsection Description-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc12">2.2.1</A>Description</H4><!--SEC END --><P>
A description is a line-separated list of <I>rules</I>.
</P><!--TOC subsubsection Rule-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc13">2.2.2</A>Rule</H4><!--SEC END --><P>
A rule is a line of the form
</P><BLOCKQUOTE CLASS="quote">
(<I>pattern</I>)<I>:type</I><I>:modelist</I> <I>action</I>
</BLOCKQUOTE><P>
Only the pattern part is mandatory, though most rules also include
an action and a type.</P><!--TOC subsubsection Pattern-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc14">2.2.3</A>Pattern</H4><!--SEC END --><P>
A pattern is a comma-separated list of <I>pattern atoms</I>.</P><!--TOC subsubsection Type-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc15">2.2.4</A>Type</H4><!--SEC END --><P>
The type of a rule is a standard GP2C type.</P><!--TOC subsubsection Modelist-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc16">2.2.5</A>Modelist</H4><!--SEC END --><P>
A modelist is a colon-separated list of <I>modes</I>.</P><!--TOC subsubsection Action-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc17">2.2.6</A>Action</H4><!--SEC END --><P>An action is a string (normally a piece of C code) that can
include <I>replacement strings</I>. Replacement strings start by
a $ and are substituted according to the replacement rules.</P><!--TOC subsection Pattern atom-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc18">2.3</A>Pattern atom</H3><!--SEC END --><P>A pattern atom is one of the following, where <I>type</I> is any GP2C type,
<I>n</I> any small integer, <I>"str"</I> any character string and <I>ctype</I>
any C-type. A pattern atom can match an object.</P><UL CLASS="itemize"><LI CLASS="li-itemize">
<I>type</I>. This matches any object of type comparable to <I>type</I>.
</LI><LI CLASS="li-itemize"><I>n</I>. This matches a constant small integer value equal to <I>n</I>.
</LI><LI CLASS="li-itemize"><I>?n</I>. This matches an optional <I>small</I> value which defaults to
<I>n</I>.
</LI><LI CLASS="li-itemize"><I>?type</I>. This matches an optional <I>type</I> value with standard default value.
</LI><LI CLASS="li-itemize"><I>"str"</I>. This matches a constant character string equal to <I>str</I>.
</LI><LI CLASS="li-itemize"><I>&type</I>. This matches a reference (the GP <I>&x</I> construction) to
an object of type equal or less than <I>type</I> referencing the same data type.
</LI><LI CLASS="li-itemize"><I>nothing</I>. This matches a missing argument.
</LI><LI CLASS="li-itemize"><I>#type</I>. This matches a constant value of type <I>type</I>.
</LI><LI CLASS="li-itemize"><I>...</I> This matches any number of arguments matching the previous atom.
This must be the last atom of the pattern. This allows to implement functions
taking an unlimited number of arguments.
</LI><LI CLASS="li-itemize"><I>C!ctype</I>. This matches any object of C-type <I>ctype</I>.
</LI><LI CLASS="li-itemize"><I>@type</I>. This matches a variable of type <I>type</I>. This is mainly used
for expressions that evaluate their arguments several times.
</LI><LI CLASS="li-itemize"><I>*type</I>. This matches an lvalue of type <I>type</I>. This is used in
constructions that modify their arguments.
</LI></UL><!--TOC subsection Matching-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc19">2.4</A>Matching</H3><!--SEC END --><P>The best rule is determined as follows:
</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
The result of matching a pattern atom against some GP code is
either ’reject’ or ’match’.
</LI><LI CLASS="li-enumerate">There are three matching levels: ’partial’, ’normal’ and ’perfect’.
</LI><LI CLASS="li-enumerate">A pattern matches if all the atoms match.
</LI><LI CLASS="li-enumerate">A rule matches if its pattern matches.
</LI><LI CLASS="li-enumerate">The best rule is the matching rule with the higher number of normal
and perfect matches. In case of a tie, the highest number of perfect matches
wins. If there is still a tie, the topmost rule wins.
</LI></OL><P>When matching the pattern atoms <I>type</I> and <I>?type</I>, the matching
level is determined as follows:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
a perfect match occurs when the type of the object is exactly <I>type</I>,
</LI><LI CLASS="li-itemize">a normal match when the type is less than <I>type</I>,
</LI><LI CLASS="li-itemize">a partial match when the type is bigger than <I>type</I>.
</LI><LI CLASS="li-itemize">Rejection happens when the types are uncomparable.
</LI></UL><P>
Other pattern atoms always result in a reject or a perfect match.</P><!--TOC subsection Mode-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc20">2.5</A>Mode</H3><!--SEC END --><P>
Modes are used in descriptions to give more information to GP2C about the
action part. They are usually useless to human beings that are smart
enough to understand the action part. The current list of modes is:
</P><DL CLASS="description"><DT CLASS="dt-description">
<B>prec</B></DT><DD CLASS="dd-description"> The action uses the <FONT COLOR=purple>prec</FONT> variable.
</DD><DT CLASS="dt-description"><B>parens</B></DT><DD CLASS="dd-description"> The action does not have top precedence. GP2C will put it between
parentheses when needed (see $())
</DD><DT CLASS="dt-description"><B>copy</B></DT><DD CLASS="dd-description"> The action returns data that access memory belonging to other
objects. GP2C will generate calls to <FONT COLOR=purple>gcopy()</FONT> when needed.
</DD></DL><!--TOC subsection Lists of replacement strings-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc21">2.6</A>Lists of replacement strings</H3><!--SEC END --><P>The following special sequences can occur in the action part:
</P><UL CLASS="itemize"><LI CLASS="li-itemize"><FONT COLOR=purple>$n</FONT>. This is replaced by the <I>n</I>-th argument of the function.</LI><LI CLASS="li-itemize"><FONT COLOR=purple>$(n)</FONT>. This is replaced by the <I>n</I>-th argument of the function
between parenthesis if it has the parens mode.</LI><LI CLASS="li-itemize"><FONT COLOR=purple>$type:n</FONT>. This is replaced by the <I>n</I>-th argument of the
function cast to type <I>type</I>.</LI><LI CLASS="li-itemize"><FONT COLOR=purple>$(type:n)</FONT>. Combination of $(n) and $type:n.</LI><LI CLASS="li-itemize"><FONT COLOR=purple>$%n</FONT>. This is replaced by the <I>n</I>-th argument of the function,
which must be a constant string, with all % characters doubled and no quotes.
This is for use inside format specification.</LI><LI CLASS="li-itemize"><FONT COLOR=purple>$"message"</FONT>. Signals an invalid condition. GP2C will abort by
printing the error message <FONT COLOR=purple>message</FONT>.</LI><LI CLASS="li-itemize"><FONT COLOR=purple>${RPN sequence}</FONT>
The RPN sequence is a space separated list of RPN commands that will be
evaluated by the GP2C internal RPN evaluator.
If the stack is empty at the end of the evaluation, this is replaced by
the empty string, else this is replaced by the integer at the top of the
stack. Some RPN commands generate text, in that case it is pasted just before
the $ sign.
</LI></UL><!--TOC subsection Lists of RPN commands-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc22">2.7</A>Lists of RPN commands</H3><!--SEC END --><P>
The commands are evaluated with respect to a stack of integer values,
initially empty.
The exact list of command supported by a particular GP2C version is the
<FONT COLOR=purple>%accepted_command</FONT> hash in the script <TT>scripts/822_desc.pl.in</TT>.</P><DL CLASS="description"><DT CLASS="dt-description">
<B><I>literal integer</I></B></DT><DD CLASS="dd-description"> push the integer at the top of the stack.
</DD><DT CLASS="dt-description"><B>:</B><B><I>type</I></B></DT><DD CLASS="dd-description"> push the type <I>type</I> at the top of the stack.
</DD><DT CLASS="dt-description"><B>add, sub, mul, div, mod</B></DT><DD CLASS="dd-description"> 2-ary arithmetic operators
</DD><DT CLASS="dt-description"><B>neg</B></DT><DD CLASS="dd-description"> 1-ary arithmetic operator
</DD><DT CLASS="dt-description"><B>and, or, xor</B></DT><DD CLASS="dd-description"> 2-ary logical operators
</DD><DT CLASS="dt-description"><B>not</B></DT><DD CLASS="dd-description"> 1-ary logical operator
</DD><DT CLASS="dt-description"><B>type</B></DT><DD CLASS="dd-description"> pop an integer <I>n</I> and push the type of the <I>n</I>-th argument.
</DD><DT CLASS="dt-description"><B>value</B></DT><DD CLASS="dd-description"> pop an integer <I>n</I> and push the value of the <I>n</I>-th argument,
provided it is a constant integer.
</DD><DT CLASS="dt-description"><B>code</B></DT><DD CLASS="dd-description"> pop an integer <I>n</I> and generate the C code for the <I>n</I>-th argument.
</DD><DT CLASS="dt-description"><B>cast</B></DT><DD CLASS="dd-description"> pop an integer <I>n</I> and a type <I>t</I> and generate the C code for the
<I>n</I>-th argument cast to type <I>t</I>.
</DD><DT CLASS="dt-description"><B>parens</B></DT><DD CLASS="dd-description"> this is a flag requesting <B>code</B> and <B>cast</B> to enclose
the C code between parenthesis if the argument has the <I>parens</I> mode.
</DD><DT CLASS="dt-description"><B>str_format, str_raw</B></DT><DD CLASS="dd-description"> pop an integer <I>n</I> such that the <I>n</I>-th argument
is a constant string and display the string without leading and ending ".
Furthermore <B>str_format</B> will display the string in a way suitable for
inclusion in a format string by quoting meta-characters.
</DD></DL><P>The following RPN commands are useful with the <I>...</I> pattern atom to
implement functions that take an unlimited number of arguments.
</P><DL CLASS="description"><DT CLASS="dt-description">
<B>nbarg</B></DT><DD CLASS="dd-description"> push the actual number of arguments of the function.
</DD><DT CLASS="dt-description"><B>format_string, format_args</B></DT><DD CLASS="dd-description"> pop an integer <I>n</I> such that the <I>n</I>-th
argument corresponds to a <I>...</I> pattern atom and generate a format string
and a list of arguments, see the description of the GP function <I>print</I>.
</DD><DT CLASS="dt-description"><B>code, cast</B></DT><DD CLASS="dd-description"> If the integer <I>n</I> corresponds to a <I>...</I> pattern atom,
generate a comma-separated list of C code for the arguments <I>n</I>−1, <I>n</I>, <I>n</I>+1,
…, <B>nbarg</B>, by matching each argument against the <I>n</I>−1 pattern atom.
</DD><DT CLASS="dt-description"><B>stdref</B></DT><DD CLASS="dd-description"> this is a flag requesting <B>code</B> and <B>type</B> to
prepend a ’&’ before each arguments.
</DD></DL><P>
The following RPN commands are useful to implement functions that take closures
as arguments.
</P><DL CLASS="description"><DT CLASS="dt-description">
<B>wrapper, cookie</B></DT><DD CLASS="dd-description"> pop an integer <I>n</I> and generate a call to the wrapper
(resp. the cookie associated to the wrapper) for the <I>n</I>-th argument. The
wrapper generated depends on the wrapper prototype in the Wrapper field.
The cookie is the list of local variables seen by the closure.
</DD></DL><!--CUT END -->
<!--HTMLFOOT-->
<!--ENDHTML-->
<!--FOOTER-->
<HR SIZE=2><BLOCKQUOTE CLASS="quote"><EM>This document was translated from L<sup>A</sup>T<sub>E</sub>X by
</EM><A HREF="http://hevea.inria.fr/index.html"><EM>H</EM><EM><FONT SIZE=2><sup>E</sup></FONT></EM><EM>V</EM><EM><FONT SIZE=2><sup>E</sup></FONT></EM><EM>A</EM></A><EM>.</EM></BLOCKQUOTE></BODY>
</HTML>
|
