bison_6.htm

Lex和Yacc的Manual

  double val;
  symrec *tptr;
}
%token <val> NUM      /* define token NUM and its type */
</PRE>

<P>
You can associate a literal string token with a token type name by
writing the literal string at the end of a <CODE>%token</CODE>
declaration which declares the name.  For example:

</P>

<PRE>
%token arrow "=&#62;"
</PRE>

<P>
For example, a grammar for the C language might specify these names with
equivalent literal string tokens:

</P>

<PRE>
%token  &#60;operator&#62;  OR      "||"
%token  &#60;operator&#62;  LE 134  "&#60;="
%left  OR  "&#60;="
</PRE>

<P>
Once you equate the literal string and the token name, you can use them
interchangeably in further declarations or the grammar rules.  The
<CODE>yylex</CODE> function can use the token name or the literal string to
obtain the token type code number (see section <A HREF="bison_7.html#SEC62">Calling Convention for <CODE>yylex</CODE></A>).

</P>


<H3><A NAME="SEC51" HREF="index.html#SEC51">Operator Precedence</A></H3>
<P>
<A NAME="IDX96"></A>
<A NAME="IDX97"></A>
<A NAME="IDX98"></A>

</P>
<P>
Use the <CODE>%left</CODE>, <CODE>%right</CODE> or <CODE>%nonassoc</CODE> declaration to
declare a token and specify its precedence and associativity, all at
once.  These are called <STRONG>precedence declarations</STRONG>.
See section <A HREF="bison_8.html#SEC71">Operator Precedence</A>, for general information on operator precedence.

</P>
<P>
The syntax of a precedence declaration is the same as that of
<CODE>%token</CODE>: either

</P>

<PRE>
%left <VAR>symbols</VAR>...
</PRE>

<P>
or

</P>

<PRE>
%left &#60;<VAR>type</VAR>&#62; <VAR>symbols</VAR>...
</PRE>

<P>
And indeed any of these declarations serves the purposes of <CODE>%token</CODE>.
But in addition, they specify the associativity and relative precedence for
all the <VAR>symbols</VAR>:

</P>

<UL>
<LI>

The associativity of an operator <VAR>op</VAR> determines how repeated uses
of the operator nest: whether <SAMP>`<VAR>x</VAR> <VAR>op</VAR> <VAR>y</VAR> <VAR>op</VAR>
<VAR>z</VAR>'</SAMP> is parsed by grouping <VAR>x</VAR> with <VAR>y</VAR> first or by
grouping <VAR>y</VAR> with <VAR>z</VAR> first.  <CODE>%left</CODE> specifies
left-associativity (grouping <VAR>x</VAR> with <VAR>y</VAR> first) and
<CODE>%right</CODE> specifies right-associativity (grouping <VAR>y</VAR> with
<VAR>z</VAR> first).  <CODE>%nonassoc</CODE> specifies no associativity, which
means that <SAMP>`<VAR>x</VAR> <VAR>op</VAR> <VAR>y</VAR> <VAR>op</VAR> <VAR>z</VAR>'</SAMP> is
considered a syntax error.

<LI>

The precedence of an operator determines how it nests with other operators.
All the tokens declared in a single precedence declaration have equal
precedence and nest together according to their associativity.
When two tokens declared in different precedence declarations associate,
the one declared later has the higher precedence and is grouped first.
</UL>



<H3><A NAME="SEC52" HREF="index.html#SEC52">The Collection of Value Types</A></H3>
<P>
<A NAME="IDX99"></A>
<A NAME="IDX100"></A>
<A NAME="IDX101"></A>

</P>
<P>
The <CODE>%union</CODE> declaration specifies the entire collection of possible
data types for semantic values.  The keyword <CODE>%union</CODE> is followed by a
pair of braces containing the same thing that goes inside a <CODE>union</CODE> in
C.  

</P>
<P>
For example:

</P>

<PRE>
%union {
  double val;
  symrec *tptr;
}
</PRE>

<P>
This says that the two alternative types are <CODE>double</CODE> and <CODE>symrec
*</CODE>.  They are given names <CODE>val</CODE> and <CODE>tptr</CODE>; these names are used
in the <CODE>%token</CODE> and <CODE>%type</CODE> declarations to pick one of the types
for a terminal or nonterminal symbol (see section <A HREF="bison_6.html#SEC53">Nonterminal Symbols</A>).

</P>
<P>
Note that, unlike making a <CODE>union</CODE> declaration in C, you do not write
a semicolon after the closing brace.

</P>


<H3><A NAME="SEC53" HREF="index.html#SEC53">Nonterminal Symbols</A></H3>
<P>
<A NAME="IDX102"></A>
<A NAME="IDX103"></A>
<A NAME="IDX104"></A>

</P>
<P>
When you use <CODE>%union</CODE> to specify multiple value types, you must
declare the value type of each nonterminal symbol for which values are
used.  This is done with a <CODE>%type</CODE> declaration, like this:

</P>

<PRE>
%type &#60;<VAR>type</VAR>&#62; <VAR>nonterminal</VAR>...
</PRE>

<P>
Here <VAR>nonterminal</VAR> is the name of a nonterminal symbol, and <VAR>type</VAR>
is the name given in the <CODE>%union</CODE> to the alternative that you want
(see section <A HREF="bison_6.html#SEC52">The Collection of Value Types</A>).  You can give any number of nonterminal symbols in
the same <CODE>%type</CODE> declaration, if they have the same value type.  Use
spaces to separate the symbol names.

</P>
<P>
You can also declare the value type of a terminal symbol.  To do this,
use the same <CODE>&#60;<VAR>type</VAR>&#62;</CODE> construction in a declaration for the
terminal symbol.  All kinds of token declarations allow
<CODE>&#60;<VAR>type</VAR>&#62;</CODE>.

</P>


<H3><A NAME="SEC54" HREF="index.html#SEC54">Suppressing Conflict Warnings</A></H3>
<P>
<A NAME="IDX105"></A>
<A NAME="IDX106"></A>
<A NAME="IDX107"></A>
<A NAME="IDX108"></A>
<A NAME="IDX109"></A>

</P>
<P>
Bison normally warns if there are any conflicts in the grammar
(see section <A HREF="bison_8.html#SEC70">Shift/Reduce Conflicts</A>), but most real grammars have harmless shift/reduce
conflicts which are resolved in a predictable way and would be difficult to
eliminate.  It is desirable to suppress the warning about these conflicts
unless the number of conflicts changes.  You can do this with the
<CODE>%expect</CODE> declaration.

</P>
<P>
The declaration looks like this:

</P>

<PRE>
%expect <VAR>n</VAR>
</PRE>

<P>
Here <VAR>n</VAR> is a decimal integer.  The declaration says there should be no
warning if there are <VAR>n</VAR> shift/reduce conflicts and no reduce/reduce
conflicts.  The usual warning is given if there are either more or fewer
conflicts, or if there are any reduce/reduce conflicts.

</P>
<P>
In general, using <CODE>%expect</CODE> involves these steps:

</P>

<UL>
<LI>

Compile your grammar without <CODE>%expect</CODE>.  Use the <SAMP>`-v'</SAMP> option
to get a verbose list of where the conflicts occur.  Bison will also
print the number of conflicts.

<LI>

Check each of the conflicts to make sure that Bison's default
resolution is what you really want.  If not, rewrite the grammar and
go back to the beginning.

<LI>

Add an <CODE>%expect</CODE> declaration, copying the number <VAR>n</VAR> from the
number which Bison printed.
</UL>

<P>
Now Bison will stop annoying you about the conflicts you have checked, but
it will warn you again if changes in the grammar result in additional
conflicts.

</P>


<H3><A NAME="SEC55" HREF="index.html#SEC55">The Start-Symbol</A></H3>
<P>
<A NAME="IDX110"></A>
<A NAME="IDX111"></A>
<A NAME="IDX112"></A>
<A NAME="IDX113"></A>

</P>
<P>
Bison assumes by default that the start symbol for the grammar is the first
nonterminal specified in the grammar specification section.  The programmer
may override this restriction with the <CODE>%start</CODE> declaration as follows:

</P>

<PRE>
%start <VAR>symbol</VAR>
</PRE>



<H3><A NAME="SEC56" HREF="index.html#SEC56">A Pure (Reentrant) Parser</A></H3>
<P>
<A NAME="IDX114"></A>
<A NAME="IDX115"></A>
<A NAME="IDX116"></A>

</P>
<P>
A <STRONG>reentrant</STRONG> program is one which does not alter in the course of
execution; in other words, it consists entirely of <STRONG>pure</STRONG> (read-only)
code.  Reentrancy is important whenever asynchronous execution is possible;
for example, a nonreentrant program may not be safe to call from a signal
handler.  In systems with multiple threads of control, a nonreentrant
program must be called only within interlocks.

</P>
<P>
The Bison parser is not normally a reentrant program, because it uses
statically allocated variables for communication with <CODE>yylex</CODE>.  These
variables include <CODE>yylval</CODE> and <CODE>yylloc</CODE>.

</P>
<P>
The Bison declaration <CODE>%pure_parser</CODE> says that you want the parser
to be reentrant.  It looks like this:

</P>

<PRE>
%pure_parser
</PRE>

<P>
The effect is that the two communication variables become local
variables in <CODE>yyparse</CODE>, and a different calling convention is used
for the lexical analyzer function <CODE>yylex</CODE>.  See section <A HREF="bison_7.html#SEC65">Calling Conventions for Pure Parsers</A>, for the details of this.  The
variable <CODE>yynerrs</CODE> also becomes local in <CODE>yyparse</CODE>
(see section <A HREF="bison_7.html#SEC66">The Error Reporting Function <CODE>yyerror</CODE></A>).
The convention for calling <CODE>yyparse</CODE> itself is unchanged.

</P>


<H3><A NAME="SEC57" HREF="index.html#SEC57">Bison Declaration Summary</A></H3>
<P>
<A NAME="IDX117"></A>
<A NAME="IDX118"></A>
<A NAME="IDX119"></A>

</P>
<P>
Here is a summary of all Bison declarations:

</P>
<DL COMPACT>

<DT><CODE>%union</CODE>
<DD>
Declare the collection of data types that semantic values may have
(see section <A HREF="bison_6.html#SEC52">The Collection of Value Types</A>).

<DT><CODE>%token</CODE>
<DD>
Declare a terminal symbol (token type name) with no precedence
or associativity specified (see section <A HREF="bison_6.html#SEC50">Token Type Names</A>).

<DT><CODE>%right</CODE>
<DD>
Declare a terminal symbol (token type name) that is right-associative
(see section <A HREF="bison_6.html#SEC51">Operator Precedence</A>).

<DT><CODE>%left</CODE>
<DD>
Declare a terminal symbol (token type name) that is left-associative
(see section <A HREF="bison_6.html#SEC51">Operator Precedence</A>).

<DT><CODE>%nonassoc</CODE>
<DD>
Declare a terminal symbol (token type name) that is nonassociative
(using it in a way that would be associative is a syntax error)
(see section <A HREF="bison_6.html#SEC51">Operator Precedence</A>).

<DT><CODE>%type</CODE>
<DD>
Declare the type of semantic values for a nonterminal symbol
(see section <A HREF="bison_6.html#SEC53">Nonterminal Symbols</A>).

<DT><CODE>%start</CODE>
<DD>
Specify the grammar's start symbol (see section <A HREF="bison_6.html#SEC55">The Start-Symbol</A>).

<DT><CODE>%expect</CODE>
<DD>
Declare the expected number of shift-reduce conflicts
(see section <A HREF="bison_6.html#SEC54">Suppressing Conflict Warnings</A>).

<DT><CODE>%pure_parser</CODE>
<DD>
Request a pure (reentrant) parser program (see section <A HREF="bison_6.html#SEC56">A Pure (Reentrant) Parser</A>).

<DT><CODE>%no_lines</CODE>
<DD>
Don't generate any <CODE>#line</CODE> preprocessor commands in the parser
file.  Ordinarily Bison writes these commands in the parser file so that
the C compiler and debuggers will associate errors and object code with
your source file (the grammar file).  This directive causes them to
associate errors with the parser file, treating it an independent source
file in its own right.

<DT><CODE>%raw</CODE>
<DD>
The output file <TT>`<VAR>name</VAR>.h'</TT> normally defines the tokens with
Yacc-compatible token numbers.  If this option is specified, the
internal Bison numbers are used instead.  (Yacc-compatible numbers start
at 257 except for single character tokens; Bison assigns token numbers
sequentially for all tokens starting at 3.)

<DT><CODE>%token_table</CODE>
<DD>
Generate an array of token names in the parser file.  The name of the
array is <CODE>yytname</CODE>; <CODE>yytname[<VAR>i</VAR>]</CODE> is the name of the
token whose internal Bison token code number is <VAR>i</VAR>.  The first three
elements of <CODE>yytname</CODE> are always <CODE>"$"</CODE>, <CODE>"error"</CODE>, and
<CODE>"$illegal"</CODE>; after these come the symbols defined in the grammar
file.

For single-character literal tokens and literal string tokens, the name
in the table includes the single-quote or double-quote characters: for
example, <CODE>"'+'"</CODE> is a single-character literal and <CODE>"\"&#60;=\""</CODE>
is a literal string token.  All the characters of the literal string
token appear verbatim in the string found in the table; even
double-quote characters are not escaped.  For example, if the token
consists of three characters <SAMP>`*"*'</SAMP>, its string in <CODE>yytname</CODE>
contains <SAMP>`"*"*"'</SAMP>.  (In C, that would be written as
<CODE>"\"*\"*\""</CODE>).

When you specify <CODE>%token_table</CODE>, Bison also generates macro
definitions for macros <CODE>YYNTOKENS</CODE>, <CODE>YYNNTS</CODE>, and
<CODE>YYNRULES</CODE>, and <CODE>YYNSTATES</CODE>:

<DL COMPACT>

<DT><CODE>YYNTOKENS</CODE>
<DD>
The highest token number, plus one.
<DT><CODE>YYNNTS</CODE>
<DD>
The number of non-terminal symbols.
<DT><CODE>YYNRULES</CODE>
<DD>
The number of grammar rules,
<DT><CODE>YYNSTATES</CODE>
<DD>
The number of parser states (see section <A HREF="bison_8.html#SEC77">Parser States</A>).
</DL>
</DL>



<H2><A NAME="SEC58" HREF="index.html#SEC58">Multiple Parsers in the Same Program</A></H2>

<P>
Most programs that use Bison parse only one language and therefore contain
only one Bison parser.  But what if you want to parse more than one
language with the same program?  Then you need to avoid a name conflict
between different definitions of <CODE>yyparse</CODE>, <CODE>yylval</CODE>, and so on.

</P>
<P>
The easy way to do this is to use the option <SAMP>`-p <VAR>prefix</VAR>'</SAMP>
(see section <A HREF="bison_12.html#SEC87">Invoking Bison</A>).  This renames the interface functions and
variables of the Bison parser to start with <VAR>prefix</VAR> instead of
<SAMP>`yy'</SAMP>.  You can use this to give each parser distinct names that do
not conflict.

</P>
<P>
The precise list of symbols renamed is <CODE>yyparse</CODE>, <CODE>yylex</CODE>,
<CODE>yyerror</CODE>, <CODE>yynerrs</CODE>, <CODE>yylval</CODE>, <CODE>yychar</CODE> and
<CODE>yydebug</CODE>.  For example, if you use <SAMP>`-p c'</SAMP>, the names become
<CODE>cparse</CODE>, <CODE>clex</CODE>, and so on.

</P>
<P>
<STRONG>All the other variables and macros associated with Bison are not
renamed.</STRONG> These others are not global; there is no conflict if the same
name is used in different parsers.  For example, <CODE>YYSTYPE</CODE> is not
renamed, but defining this in different ways in different parsers causes
no trouble (see section <A HREF="bison_6.html#SEC44">Data Types of Semantic Values</A>).

</P>
<P>
The <SAMP>`-p'</SAMP> option works by adding macro definitions to the beginning
of the parser source file, defining <CODE>yyparse</CODE> as
<CODE><VAR>prefix</VAR>parse</CODE>, and so on.  This effectively substitutes one
name for the other in the entire parser file.

</P>
<HR>
Go to the <A HREF="bison_1.html">first</A>, <A HREF="bison_5.html">previous</A>, <A HREF="bison_7.html">next</A>, <A HREF="bison_15.html">last</A> section, <A HREF="index.html">table of contents</A>.
</BODY>
</HTML>