/usr/share/mozart/doc/gump/node7.html is in mozart-doc 1.4.0-8ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>3.2 Reference</TITLE><LINK href="ozdoc.css" rel="stylesheet" type="text/css"></HEAD><BODY><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node6.html#section.parser.example"><< Prev</A></TD><TD><A href="node5.html">- Up -</A></TD></TR></TABLE><DIV id="section.parser.reference"><H2><A name="section.parser.reference">3.2 Reference</A></H2><P> This section is the reference manual for the Gump Parser Generator. It is divided into three parts: First, the syntax of the Gump parser specification language is given in <A href="node7.html#section.parser.syntax">Section 3.2.1</A>. Then, the options to parser generation supported by the Gump Parser Generator are detailed in <A href="node7.html#section.parser.params">Section 3.2.2</A>. Finally, the runtime support for generated parsers, the mixin class <CODE>GumpParser<SPAN class="keyword">.</SPAN><SPAN class="string">'class'</SPAN></CODE>, is presented in <A href="node7.html#section.parser.class">Section 3.2.3</A>. </P><DIV id="section.parser.syntax"><H3><A name="section.parser.syntax">3.2.1 Syntax of the Parser Specification Language</A></H3><P> The meta-notation used for describing the syntax of the specification language is explained in <A href="node8.html#appendix.notation">Appendix A</A>. (Note: This is <EM>not</EM> the language used in Gump to specify parsers. This is intentional.) </P><P> Gump specifications are allowed anywhere as a statement. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>statement</I>></TD><TD align="center"> += </TD><TD><<I>parser specification</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><P> A parser specification is introduced by the keyword <CODE><SPAN class="keyword">parser</SPAN></CODE>, followed by the usual components of an Oz class. After these come additional parser-specific descriptors. Parser specifications must be named by variables, since the names of these variables will be used to generate auxiliary file names during parser generation. <A name="label213"></A> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>parser specification</I>></TD><TD align="center"> ::= </TD><TD><CODE><SPAN class="keyword">parser</SPAN></CODE> <<I>variable</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"></TD><TD>{ <<I>class descriptor</I>> }</TD></TR><TR valign="top"><TD></TD><TD align="center"></TD><TD>{ <<I>method</I>> }</TD></TR><TR valign="top"><TD></TD><TD align="center"></TD><TD>[ <<I>token clause</I>> ]</TD></TR><TR valign="top"><TD></TD><TD align="center"></TD><TD>{ <<I>parser descriptor</I>> }+</TD></TR><TR valign="top"><TD></TD><TD align="center"></TD><TD><CODE><SPAN class="keyword">end</SPAN></CODE></TD></TR></TABLE></BLOCKQUOTE><P> </P><H4><A name="label214">Token Declarations</A></H4><P> <A name="label215"></A> The first extra parser descriptor is the <CODE><SPAN class="keyword">token</SPAN></CODE> clause. This defines the names of the terminals used in the specification as well as (optionally) their associativity and precedence. Several tokens are predefined: Atoms of length 1 are always considered to be tokens. Furthermore, token <A name="label216"></A><SPAN class="index"><CODE><SPAN class="string">'error'</SPAN></CODE></SPAN><A name="label217"></A><A name="label218"></A> stands for an erroneous token (sequence) and is used for error recovery<A name="label219"></A>, and token <A name="label220"></A><SPAN class="index"><CODE><SPAN class="string">'EOF'</SPAN></CODE></SPAN> <A name="label221"></A><A name="label222"></A> signalizes the end of input and is always expected before reduction to the start symbol can take place. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>token clause</I>></TD><TD align="center"> ::= </TD><TD><CODE><SPAN class="keyword">token</SPAN></CODE> { <<I>token declaration</I>> }+</TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>token declaration</I>></TD><TD align="center"> ::= </TD><TD><<I>atom</I>> [ <SPAN class="terminal">"<CODE>:</CODE>"</SPAN> <<I>expression</I>> ]</TD></TR></TABLE></BLOCKQUOTE><P> </P><P> The optional expression following the colon in a token declaration must be a tuple with arity 1 and one of the labels <A name="label223"></A><SPAN class="index"><CODE>leftAssoc</CODE></SPAN>, <A name="label224"></A><SPAN class="index"><CODE>rightAssoc</CODE></SPAN> or <A name="label225"></A><SPAN class="index"><CODE>nonAssoc</CODE></SPAN>, depending on the desired associativity. The feature must always be a nonzero positive integer. Only the relative values matter; they are used to derive an ordering on the tokens. Larger values imply a greater binding strength of the operator. For the algorithm used to resolve conflicts using operator precedence information, refer to the <A name="label226"></A><SPAN class="index"><SPAN class="tool">bison</SPAN></SPAN> manual <A href="bib.html#donellystallman95">[DS95]</A>. </P><H4><A name="label227">Syntax Rules</A></H4><P> <A name="label228"></A> Syntax rules are parser descriptors. They are composed of a head and a body. The head specifies the name of the defined nonterminal, where atoms are considered start symbols, as well as the formal parameters of the nonterminal. Only one syntax rule per nonterminal name is allowed. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>parser descriptor</I>></TD><TD align="center"> ::= </TD><TD><<I>syn clause</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn clause</I>></TD><TD align="center"> ::= </TD><TD><CODE><SPAN class="keyword">syn</SPAN></CODE> <<I>syn head</I>> <<I>syn alt</I>> <CODE><SPAN class="keyword">end</SPAN></CODE></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn head</I>></TD><TD align="center"> ::= </TD><TD><<I>atom</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>atom label</I>> <<I>syn formals</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>variable</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>variable label</I>> <<I>syn formals</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn formals</I>></TD><TD align="center"> ::= </TD><TD><SPAN class="terminal">"<CODE>(</CODE>"</SPAN> { <<I>syn formal</I>> } <SPAN class="terminal">"<CODE>)</CODE>"</SPAN></TD></TR></TABLE></BLOCKQUOTE><P> </P><P> The body of a syntax rule is an EBNF phrase. It is distinguished between EBNF statements and EBNF expressions: EBNF expressions carry an additional value. In the following, it is always specified where EBNF statements or expressions are expected and which constructs yield a value. </P><P> Formal parameters are denoted by variables. At most one parameter may be the nesting marker; in this case the body of the syntax rule must be an EBNF expression. Its value is unified with the corresponding actual parameter upon application of the nonterminal. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn formal</I>></TD><TD align="center"> ::= </TD><TD><<I>variable</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><SPAN class="terminal">"<CODE>_</CODE>"</SPAN></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><SPAN class="terminal">"<CODE>$</CODE>"</SPAN></TD></TR></TABLE></BLOCKQUOTE><P> </P><P> An alternation specifies several sequences (called <A name="label229"></A><EM>alternatives</EM>), separated by the choice operator <CODE><SPAN class="keyword">[]</SPAN></CODE>. Either all sequences must be EBNF expressions or all sequences must be EBNF statements. If all alternatives are expressions, the alternation is an expression and yields at runtime the value of the selected sequence at runtime. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn alt</I>></TD><TD align="center"> ::= </TD><TD><<I>syn seq</I>> { <SPAN class="terminal">"<CODE><SPAN class="keyword">[]</SPAN></CODE>"</SPAN> <<I>syn seq</I>> }</TD></TR></TABLE></BLOCKQUOTE><P> </P><P> At the beginning of an sequence, <A name="label230"></A><SPAN class="index">local variables</SPAN> may be declared. These are visible only inside the sequence. The sequence itself is composed of <I
>n</I> >= 0 EBNF factors, optionally followed by a semantic action. If an EBNF expression is expected at the place the sequence stands, then a semantic action<A name="label231"></A> must either be an expression or be omitted. In the latter case, the last EBNF phrase must be an EBNF expression, the value of the sequence then is the value of this EBNF expression. All other EBNF factors must be statements. If <I>n</I> = 0, then the sequence may be written as <A name="label232"></A><SPAN class="index"><CODE><SPAN class="keyword">skip</SPAN></CODE></SPAN>.<A name="label233"></A> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn seq</I>></TD><TD align="center"> ::= </TD><TD>[ { <<I>variable</I>> }+ <CODE><SPAN class="keyword">in</SPAN></CODE> ] { <<I>syn factor</I>> } [ <<I>syn action</I>> ]</TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><CODE><SPAN class="keyword">skip</SPAN></CODE> [ <<I>syn action</I>> ]</TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn action</I>></TD><TD align="center"> ::= </TD><TD><SPAN class="terminal">"<CODE><SPAN class="keyword">=></SPAN></CODE>"</SPAN> ( <<I>in statement</I>> | <<I>in expression</I>> )</TD></TR></TABLE></BLOCKQUOTE><P> </P><P> An EBNF factor is either an application or an assignment. An application is denoted by the name of either a terminal or a nonterminal, optionally followed by the actual parameters in parentheses. Terminals may either have a single (variable) parameter or no parameter at all; if a parameter is specified then it is unified with the actual token value<A name="label234"></A> at runtime. In the application of a nonterminal, the number of actual parameters must correspond to the number of formal parameters in the nonterminal's definition. Non-escaped variables as actual parameters are implicitly declared local to the innermost sequence that contains the application. At most one actual parameter may be the nesting marker. In this case, the application is an expression yielding the value of the corresponding actual parameter; else it is a statement. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn factor</I>></TD><TD align="center"> ::= </TD><TD><<I>syn application</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>syn assignment</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn application</I>></TD><TD align="center"> ::= </TD><TD><<I>atom</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>atom label</I>> <<I>syn actuals</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>variable</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>variable label</I>> <<I>syn actuals</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn actuals</I>></TD><TD align="center"> ::= </TD><TD><SPAN class="terminal">"<CODE>(</CODE>"</SPAN> { <<I>expression</I>> } <SPAN class="terminal">"<CODE>)</CODE>"</SPAN></TD></TR></TABLE></BLOCKQUOTE><P> </P><P> Two grammar symbols are predefined which receive a special treatment: </P><DL><DT><CODE><SPAN class="string">'prec'</SPAN>(</CODE><I>A</I><CODE>)</CODE><A name="label235"></A> </DT><DD><P><A name="label236"></A> By inserting an application of <CODE>prec</CODE> into a sequence, the latter is assigned an associativity and a precedence. These are taken from the token <I>A</I>. Sequences that contain no application of <CODE>prec</CODE> inherit the values of the last token used in the sequence if there is one, and have no associated associativity and precedence otherwise. </P></DD><DT><CODE><SPAN class="string">'error'</SPAN></CODE><A name="label237"></A> </DT><DD><P><A name="label238"></A> <A name="label239"></A> <A name="label240"></A> <A name="label241"></A> The application of the predefined terminal <CODE><SPAN class="string">'error'</SPAN></CODE> defines a restart point for error recovery. Consult the <A name="label242"></A><SPAN class="index"><SPAN class="tool">bison</SPAN></SPAN> manual <A href="bib.html#donellystallman95">[DS95]</A> for additional information. </P></DD></DL><P> </P><P> An assignment equates a variable with the value of an EBNF expression. Unless the variable is escaped, it is implicitly declared local to the sequence the assignment appears in, else it must have been declared local within the current syntax rule (or be a formal parameter). An assignment is always a statement. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn assignment</I>></TD><TD align="center"> ::= </TD><TD>[ <SPAN class="terminal">"<CODE><SPAN class="keyword">!</SPAN></CODE>"</SPAN> ] <<I>variable</I>> <SPAN class="terminal">"<CODE>=</CODE>"</SPAN> <<I>syn factor</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><H4><A name="label243">Definition of Production Templates</A></H4><P> <A name="label244"></A> This section and the next augment the syntax rules defined above by the concept of <A name="label245"></A><EM>production templates</EM>. These provide for, e. g., the <A name="label246"></A><SPAN class="index">repetition</SPAN> constructs used in the example in <A href="node6.html#section.parser.example">Section 3.1</A>. </P><P> The definition of a production template is another parser descriptor. Production templates are local to the parser specification they are defined in, and may be used only textually after their definition. (This is to avoid cyclic production template expansions.) Production templates may be redefined. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>parser descriptor</I>></TD><TD align="center"> += </TD><TD><<I>prod clause</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><P> A production template definition consists of a head and a body. The body specifies the EBNF phrase the production template is to be replaced with when instantiated. The body may introduce optional local syntax rules which are always newly created when instantiated. These must be denoted by variables. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>prod clause</I>></TD><TD align="center"> ::= </TD><TD><CODE><SPAN class="keyword">prod</SPAN></CODE> <<I>prod head</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"></TD><TD>[ <<I>local rules</I>> <CODE><SPAN class="keyword">in</SPAN></CODE> ] <<I>syn alt</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"></TD><TD><CODE><SPAN class="keyword">end</SPAN></CODE></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>local rules</I>></TD><TD align="center"> ::= </TD><TD>{ <<I>syn clause</I>> }+</TD></TR></TABLE></BLOCKQUOTE><P> </P><P> The head of a production template provides - aside from the list of its formal parameters - the unique identification of the production template. This is composed of the following parts: </P><OL type="1"><LI><P>whether the production template is an expression or a statement when it is instantiated (expressions being denoted by <CODE>V=</CODE>... or <CODE>$=</CODE>...; in the head); </P></LI><LI><P>the optional identification name of the template, written before a colon; </P></LI><LI><P>the used parentheses, brackets or braces, if any; </P></LI><LI><P>the number of arguments, all being separated by <CODE><SPAN class="keyword">//</SPAN></CODE>; and </P></LI><LI><P>the used postfix operator, if any. </P></LI></OL><P> </P><P> For example, you could define the commonly used notation <CODE>[ </CODE><I>X</I><CODE> ]</CODE> as an <A name="label247"></A><SPAN class="index">EBNF</SPAN> <A name="label248"></A><SPAN class="index">option</SPAN>, or use <CODE>{ </CODE><I>X</I><CODE> <SPAN class="keyword">//</SPAN> </CODE><I>Y</I><CODE> }<SPAN class="keyword">+</SPAN></CODE> for a separated list with at least one element. This construct could yield a value, such as a list of the Oz values produced by the expression <I>X</I>, which would be denoted by the production template <I>Z</I><CODE>={ </CODE><I>X</I><CODE> <SPAN class="keyword">//</SPAN> </CODE><I>Y</I><CODE> }<SPAN class="keyword">+</SPAN></CODE>. (Compare this to the template's instantiation in <A href="node6.html#program.parser.example">Program 3.1</A> in line 21.) </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>prod head</I>></TD><TD align="center"> ::= </TD><TD><<I>template definition</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>variable</I>> <SPAN class="terminal">"<CODE>=</CODE>"</SPAN> <<I>template definition</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><SPAN class="terminal">"<CODE>$</CODE>"</SPAN> <SPAN class="terminal">"<CODE>=</CODE>"</SPAN> <<I>template definition</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>template definition</I>></TD><TD align="center"> ::= </TD><TD><<I>prod formal list</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>atom</I>> <SPAN class="terminal">"<CODE>:</CODE>"</SPAN> <<I>prod formal list</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>prod formal list</I>></TD><TD align="center"> ::= </TD><TD><SPAN class="terminal">"<CODE>(</CODE>"</SPAN> <<I>prod formals</I>> <SPAN class="terminal">"<CODE>)</CODE>"</SPAN> [ <<I>prod postfix</I>> ]</TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><SPAN class="terminal">"<CODE>[</CODE>"</SPAN> <<I>prod formals</I>> <SPAN class="terminal">"<CODE>]</CODE>"</SPAN> [ <<I>prod postfix</I>> ]</TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><SPAN class="terminal">"<CODE>{</CODE>"</SPAN> <<I>prod formals</I>> <SPAN class="terminal">"<CODE>}</CODE>"</SPAN> [ <<I>prod postfix</I>> ]</TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>variable</I>> <<I>prod postfix</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>prod formals</I>></TD><TD align="center"> ::= </TD><TD><<I>variable</I>> { <SPAN class="terminal">"<CODE><SPAN class="keyword">//</SPAN></CODE>"</SPAN> <<I>variable</I>> }</TD></TR></TABLE></BLOCKQUOTE><P></P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>prod postfix</I>></TD><TD align="center"> ::= </TD><TD><SPAN class="terminal">"<CODE><SPAN class="keyword">+</SPAN></CODE>"</SPAN> | <SPAN class="terminal">"<CODE><SPAN class="keyword">-</SPAN></CODE>"</SPAN> | <SPAN class="terminal">"<CODE><SPAN class="keyword">*</SPAN></CODE>"</SPAN> | <SPAN class="terminal">"<CODE><SPAN class="keyword">/</SPAN></CODE>"</SPAN></TD></TR></TABLE></BLOCKQUOTE><P></P><H4><A name="label249">Expansion of Production Templates</A></H4><P> Production templates may be instantiated as EBNF factors. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>syn factor</I>></TD><TD align="center"> += </TD><TD><<I>template instantiation</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><P> The instantiation of a production template is very similar to its definition, since it must specify the same unique identification. The difference is that instead of the formal parameter variables actual EBNF phrases are allowed. </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>template instantiation</I>></TD><TD align="center"> ::= </TD><TD><<I>prod actual list</I>></TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>atom</I>> <SPAN class="terminal">"<CODE>:</CODE>"</SPAN> <<I>prod actual list</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>prod actual list</I>></TD><TD align="center"> ::= </TD><TD><SPAN class="terminal">"<CODE>(</CODE>"</SPAN> <<I>prod actuals</I>> <SPAN class="terminal">"<CODE>)</CODE>"</SPAN> [ <<I>prod postfix</I>> ]</TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><SPAN class="terminal">"<CODE>[</CODE>"</SPAN> <<I>prod actuals</I>> <SPAN class="terminal">"<CODE>]</CODE>"</SPAN> [ <<I>prod postfix</I>> ]</TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><SPAN class="terminal">"<CODE>{</CODE>"</SPAN> <<I>prod actuals</I>> <SPAN class="terminal">"<CODE>}</CODE>"</SPAN> [ <<I>prod postfix</I>> ]</TD></TR><TR valign="top"><TD></TD><TD align="center"> | </TD><TD><<I>syn application</I>> <<I>prod postfix</I>></TD></TR></TABLE></BLOCKQUOTE><P> </P><BLOCKQUOTE><TABLE border="0" cellpadding="0" cellspacing="0"><TR valign="top"><TD><<I>prod actuals</I>></TD><TD align="center"> ::= </TD><TD><<I>syn alt</I>> { <SPAN class="terminal">"<CODE><SPAN class="keyword">//</SPAN></CODE>"</SPAN> <<I>syn alt</I>> }</TD></TR></TABLE></BLOCKQUOTE><P></P><P> When a production template is expanded, name clashes must be avoided. This is why the expansion proceeds in several steps: </P><UL><LI><P>The local variables of the template are uniquely renamed, both in the body's EBNF phrase as well as in the local rules. </P></LI><LI><P>The local rules are uniquely renamed to avoid confusion with other rules in the parser specification. </P></LI><LI><P>The actual EBNF phrases are substituted for the parameter variables of the production template. The formal parameter variables may only occur as applications of grammar symbols and may either be applied with a single actual parameter or none at all. If the parameter is given, then the actual EBNF phrase must be an expression whose value is unified with the application's actual parameter. </P></LI><LI><P>The local rules are quantified over the local variables used in actual EBNF phrases of the instantiation by adding these as parameters. </P></LI><LI><P>The local rules are aded to the table of grammar symbols. </P></LI><LI><P>The template instantiation is replaced by the body's EBNF phrase from the production template's definition. </P></LI></UL><P> </P><H4><A name="label250">Predefined Production Templates</A></H4><P> <A name="label251"></A> <A name="label252"></A> <A href="node7.html#table.parser.predef">Table 3.1</A> shows the predefined production templates. For many operators several equivalent notations exist. All operators also have a form that yields a value: The grouping construct yields the value of its argument, as do options (or <CODE>nil</CODE> if they are not chosen at runtime); the repetition constructs yield Oz lists of their first argument. </P><DIV class="table" id="table.parser.predef"><HR><P><A name="table.parser.predef"></A></P><P> </P><TABLE align="center" bgcolor="#f0f0e0"><TR valign="top"><TD><P>Grouping </P></TD><TD><P><CODE>( </CODE><I>A</I><CODE> )</CODE> </P></TD></TR><TR valign="top"><TD><P>Option </P></TD><TD><P><CODE>[ </CODE><I>A</I><CODE> ]</CODE> </P></TD></TR><TR valign="top"><TD><P>Mandatory Repetition </P></TD><TD><P><I>A</I><CODE><SPAN class="keyword">+</SPAN></CODE> </P><P><CODE>( </CODE><I>A</I><CODE> )<SPAN class="keyword">+</SPAN></CODE> </P><P><CODE>{ </CODE><I>A</I><CODE> }<SPAN class="keyword">+</SPAN></CODE> </P></TD></TR><TR valign="top"><TD><P>Optional Repetition </P></TD><TD><P><I>A</I><CODE><SPAN class="keyword">*</SPAN></CODE> </P><P><CODE>( </CODE><I>A</I><CODE> )<SPAN class="keyword">*</SPAN></CODE> </P><P><CODE>{ </CODE><I>A</I><CODE> }<SPAN class="keyword">*</SPAN></CODE> </P></TD></TR><TR valign="top"><TD><P>Mandatory Separated Repetition </P></TD><TD><P><CODE>( </CODE><I>A</I><CODE> <SPAN class="keyword">//</SPAN> </CODE><I>B</I><CODE> )<SPAN class="keyword">+</SPAN></CODE> </P><P><CODE>( </CODE><I>A</I><CODE> <SPAN class="keyword">//</SPAN> </CODE><I>B</I><CODE> )</CODE> </P><P><CODE>{ </CODE><I>A</I><CODE> <SPAN class="keyword">//</SPAN> </CODE><I>B</I><CODE> }<SPAN class="keyword">+</SPAN></CODE> </P><P><CODE>{ </CODE><I>A</I><CODE> <SPAN class="keyword">//</SPAN> </CODE><I>B</I><CODE> }</CODE> </P></TD></TR><TR valign="top"><TD><P>Optional Separated Repetition </P></TD><TD><P><CODE>( </CODE><I>A</I><CODE> <SPAN class="keyword">//</SPAN> </CODE><I>B</I><CODE> )<SPAN class="keyword">*</SPAN></CODE> </P><P><CODE>{ </CODE><I>A</I><CODE> <SPAN class="keyword">//</SPAN> </CODE><I>B</I><CODE> }<SPAN class="keyword">*</SPAN></CODE> </P></TD></TR></TABLE><P> </P><P class="caption"><STRONG>Table 3.1:</STRONG> Predefined production templates.</P><HR></DIV><H4><A name="label253">Assignment of Attribute Types</A></H4><P> Due to the underlying <A name="label254"></A><SPAN class="index">LR(1)</SPAN> algorithm used, two different attribute types must be distinguished concerning parameters to nonterminals, namely <EM class="noindex">synthesized</EM><A name="label255"></A><A name="label256"></A> and <A name="label257"></A><EM>inherited attributes</EM><A name="label258"></A>. This is in contrary to Oz, where input and output arguments need not be distinguished due to the concept of logical variables and unification. However, things are simplified by an algorithm determining the attribute types automatically. </P><P> Before this algorithm is explained in the following, we need to introduce a definition. </P><DIV class="apropos"><P class="margin">Definition</P><P> Let <I>S</I> be an expanded sequence (i. e., template instantiations and assignments have been expanded) with EBNF factors 0, ..., <I>n</I>. Let <I>i</I> be the index of the first EBNF factor (application or semantic action) in which a local Variable <I>V</I> (which is not a formal parameter) of the sequence occurs. Then we say that <I>V</I> is <EM class="noindex">initialized</EM> in all EBNF factors with indices <I>j</I>, <I>j</I> >= <I>i</I>, and <EM class="noindex">uninitialized </EM> in all others. </P></DIV><P> The following rules describe how attribute types are derived from their uses in applications of grammar symbols: </P><UL><LI><P>The (optional) parameter of a terminal always is a synthesized attribute (since the scanner always produces the token value). </P></LI><LI><P>Let the <I>i</I>th actual parameter of an application of a grammar symbol <I>B</I> be either an uninitialized local variable <I>V</I> or a nesting marker. Then the <I>i</I>th formal parameter of <I>B</I> is a synthesized attribute. Furthermore, <I>V</I> may not occur in any other actual parameter of the application. </P></LI><LI><P>Let the <I>i</I>th actual parameter of an application of a grammar symbol <I>B</I> be either an initialized local variable <I>V</I> or a complex Oz expression (i. e., neither a variable nor a nesting marker). Then the <I>i</I>th formal parameter of <I>B</I> is an inherited attribute. Furthermore, no uninitialized variable may occur in said actual parameter. </P></LI><LI><P>If a formal parameter of the syntax rule for a nonterminal <I>A</I> is used as actual parameter of an application of a nonterminal <I>B</I>, then the corresponding formal parameters of <I>A</I> and <I>B</I> are attributes of the same type, i. e., either both synthesized or both inherited. </P></LI></UL><P> Note that nothing can be concluded from the use of a formal parameter variable in a semantic action, since Oz does not distinguish between access of and assignment to a variable: both are realized by unification. </P><P> <A name="label259"></A> If contradicting attribute types are derived for any formal parameter variable of a nonterminal, then this is an error. If no attribute type can be derived for a formal parameter variable, then it is realized as a synthesized attribute. </P></DIV><DIV id="section.parser.params"><H3><A name="section.parser.params">3.2.2 Parameters to Parser Generation</A></H3><DIV class="apropos"><P class="margin">Macro Directives</P><P> <A name="label260"></A> The following macro directive tells the <A name="label261"></A><SPAN class="index"><SPAN class="tool">bison</SPAN></SPAN> parse table generator to expect a certain number of shift/reduce conflicts: </P><BLOCKQUOTE class="code"><CODE><SPAN class="reference">\gumpparserexpect </SPAN></CODE><<I>int</I>></BLOCKQUOTE><P> <A name="label262"></A> </P></DIV><DIV class="apropos"><P class="margin">Switches</P><P> <A href="node7.html#table.parser.params">Table 3.2</A> summarizes the options that the Gump Parser Generator understands. They may be given as compiler switches before a parser specification. </P></DIV></DIV><DIV id="section.parser.class"><DIV class="table" id="table.parser.params"><HR><P><A name="table.parser.params"></A></P><P> </P><TABLE align="center" bgcolor="#f0f0e0"><TR valign="top"><TH><P>Switch </P></TH><TH><P>Effect </P></TH></TR><TR valign="top"><TD><P><SPAN class="ignore"><CODE><SPAN class="reference">\switch +</SPAN></CODE></SPAN><CODE><SPAN class="reference">gumpparseroutputsimplified</SPAN></CODE> <A name="label263"></A> </P></TD><TD><P>create the <CODE>.simplified</CODE> file with the BNF version of the grammar </P></TD></TR><TR valign="top"><TD><P><SPAN class="ignore"><CODE><SPAN class="reference">\switch +</SPAN></CODE></SPAN><CODE><SPAN class="reference">gumpparserverbose</SPAN></CODE> <A name="label264"></A> </P></TD><TD><P>create the <CODE>.output</CODE> file with the Bison verbose output </P></TD></TR></TABLE><P> </P><P class="caption"><STRONG>Table 3.2:</STRONG> Compiler switches for the Gump Parser Generator.</P><HR></DIV><H3><A name="section.parser.class">3.2.3 The Mixin Class <CODE>GumpParser<SPAN class="keyword">.</SPAN><SPAN class="string">'class'</SPAN></CODE></A></H3><P> The mixin class <A name="label265"></A><SPAN class="index"><CODE>GumpParser<SPAN class="keyword">.</SPAN><SPAN class="string">'class'</SPAN></CODE></SPAN>, defined in the module <CODE>GumpParser</CODE>, is required to make Gump parser specifications executable. It requires some features to be present in derived classes; these are automatically inserted by the Gump Parser Generator and contain the generated parse tables. They all begin with <CODE><SPAN class="keyword">syn</SPAN></CODE>...; thus it is a good idea not to define any such named class components in order to avoid conflicts with Gump internals. Likewise, you should not define any variables beginning with <CODE>Syn</CODE>..., since such variable names are generated by the tool. </P><DIV class="apropos"><P class="margin">Abstract Members</P><P> Furthermore, the following method must be defined: </P><DL><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">synExecuteAction</SPAN>(</CODE><CODE>+<I>I</I></CODE><CODE>)</CODE> <A name="label267"></A> </DT><DD><P>This method is invoked each time a reduction takes place. The parameter <CODE><I>I</I></CODE> is the number of the rule reduced. </P></DD></DL><P> </P></DIV><DIV class="apropos"><P class="margin">Provided Members</P><P> <CODE>GumpParser<SPAN class="keyword">.</SPAN><SPAN class="string">'class'</SPAN></CODE> defines several attributes and methods that may be called by users of the generated parser or from inside semantic actions: </P><DL><DT><CODE><SPAN class="keyword">attr</SPAN> lookaheadSymbol</CODE> <A name="label269"></A> </DT><DD><P>This contains the token class of the current lookahead symbol. </P></DD><DT><CODE><SPAN class="keyword">attr</SPAN> lookaheadValue</CODE> <A name="label271"></A> </DT><DD><P>This contains the token value of the current lookahead symbol. </P></DD><DT><CODE><SPAN class="keyword">feat</SPAN> noLookahead</CODE> <A name="label273"></A> </DT><DD><P>This is the value <CODE>lookaheadSymbol</CODE> should be set to if you want to skip a token from inside a semantic action. </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">init</SPAN>(</CODE><CODE>+<I>P</I></CODE><CODE>)</CODE> <A name="label275"></A> </DT><DD><P>This initializes the internal structures of the <CODE>GumpParser<SPAN class="keyword">.</SPAN><SPAN class="string">'class'</SPAN></CODE> and connects it to a scanner <CODE><I>P</I></CODE>. <CODE><I>P</I></CODE> must at least understand the messages <CODE>putToken</CODE><A name="label277"></A> and <CODE>getToken</CODE><A name="label279"></A> as described in <A href="node4.html#section.scanner.class">Section 2.2.3</A>. </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">parse</SPAN>(</CODE><CODE>+<I>T</I></CODE><CODE> </CODE><CODE>?<I>B</I></CODE><CODE>)</CODE> <A name="label281"></A> </DT><DD><P>This methods initates a parse. The label of tuple <CODE><I>T</I></CODE> denotes the start symbol<A name="label282"></A> to use (which must be a declared nonterminal named by an atom); its features correspond to the parameters of the corresponding syntax rule. Values of inherited attributes are extracted from this tuple, values of synthesized attributes are unified with the corresponding features after the parse is finished (successfully). The parameter <CODE><I>B</I></CODE> is unified with <CODE><SPAN class="keyword">true</SPAN></CODE> if the parse was successful and with <CODE><SPAN class="keyword">false</SPAN></CODE> otherwise. </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">accept</SPAN>()</CODE> <A name="label284"></A> </DT><DD><P>By calling this method the parse is interrupted and success reported. (Note that the values of synthesized attributes of the start symbol given to <CODE>parse</CODE> are not influenced by this.) </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">abort</SPAN>()</CODE> <A name="label286"></A> </DT><DD><P>By calling this method the parse is interrupted and failure reported. (Note that the <CODE>error</CODE> method is not called.) </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">raiseError</SPAN>()</CODE> <A name="label288"></A> </DT><DD><P>This method places the parser in the same state as if a syntax error had been found in the input. Normal error recovery is attempted. The method <CODE>error</CODE> is not called. </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">errorOK</SPAN>()</CODE> <A name="label290"></A> </DT><DD><P><A name="label291"></A> When a production with a restart point (token <CODE>error</CODE>) is reduced, this method may be called to tell the parser that the error recovery process is finished and normal parsing may be resumed. </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">clearLookahead</SPAN>()</CODE> <A name="label293"></A> </DT><DD><P>When a production with a restart point (token <CODE>error</CODE>) is reduced, this method may be called to clear the lookahead token (if, for example, it was used to synchronize to the restart point and is not legal thereafter). </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">error</SPAN>(</CODE><CODE>+<I>V</I></CODE><CODE>)</CODE> <A name="label295"></A> </DT><DD><P>This method is always invoked when (during normal parsing) an error in the input is recognized. It is handed a diagnostic message in <CODE><I>V</I></CODE>. This method may be overridden in derived classes. </P></DD><DT><CODE><SPAN class="keyword">meth</SPAN> <SPAN class="functionname">getScanner</SPAN>(</CODE><CODE>?<I>P</I></CODE><CODE>)</CODE> <A name="label297"></A> </DT><DD><P>Returns the scanner object or procedure <CODE><I>P</I></CODE> currently used as the token source. </P></DD></DL><P></P></DIV></DIV></DIV><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node6.html#section.parser.example"><< Prev</A></TD><TD><A href="node5.html">- Up -</A></TD></TR></TABLE><HR><ADDRESS><A href="http://www.ps.uni-sb.de/~kornstae/">Leif Kornstaedt</A><BR><SPAN class="version">Version 1.4.0 (20110908185330)</SPAN></ADDRESS></BODY></HTML>
|