Imported Upstream version 2.6.2

[platform/upstream/bison.git] / doc / bison.info-2

This is bison.info, produced by makeinfo version 4.13 from
/Users/akim/src/gnu/bison-2.5/doc/bison.texi.

This manual (27 July 2012) is for GNU Bison (version 2.6.1-dirty), the
GNU parser generator.

   Copyright (C) 1988-1993, 1995, 1998-2012 Free Software Foundation,
Inc.

     Permission is granted to copy, distribute and/or modify this
     document under the terms of the GNU Free Documentation License,
     Version 1.3 or any later version published by the Free Software
     Foundation; with no Invariant Sections, with the Front-Cover texts
     being "A GNU Manual," and with the Back-Cover Texts as in (a)
     below.  A copy of the license is included in the section entitled
     "GNU Free Documentation License."

     (a) The FSF's Back-Cover Text is: "You have the freedom to copy and
     modify this GNU manual.  Buying copies from the FSF supports it in
     developing GNU and promoting software freedom."

INFO-DIR-SECTION Software development
START-INFO-DIR-ENTRY
* bison: (bison).       GNU parser generator (Yacc replacement).
END-INFO-DIR-ENTRY

\1f
File: bison.info,  Node: Memory Management,  Prev: Generalized LR Parsing,  Up: Algorithm

5.10 Memory Management, and How to Avoid Memory Exhaustion
==========================================================

The Bison parser stack can run out of memory if too many tokens are
shifted and not reduced.  When this happens, the parser function
`yyparse' calls `yyerror' and then returns 2.

   Because Bison parsers have growing stacks, hitting the upper limit
usually results from using a right recursion instead of a left
recursion, see *note Recursive Rules: Recursion.

   By defining the macro `YYMAXDEPTH', you can control how deep the
parser stack can become before memory is exhausted.  Define the macro
with a value that is an integer.  This value is the maximum number of
tokens that can be shifted (and not reduced) before overflow.

   The stack space allowed is not necessarily allocated.  If you
specify a large value for `YYMAXDEPTH', the parser normally allocates a
small stack at first, and then makes it bigger by stages as needed.
This increasing allocation happens automatically and silently.
Therefore, you do not need to make `YYMAXDEPTH' painfully small merely
to save space for ordinary inputs that do not need much stack.

   However, do not allow `YYMAXDEPTH' to be a value so large that
arithmetic overflow could occur when calculating the size of the stack
space.  Also, do not allow `YYMAXDEPTH' to be less than `YYINITDEPTH'.

   The default value of `YYMAXDEPTH', if you do not define it, is 10000.

   You can control how much stack is allocated initially by defining the
macro `YYINITDEPTH' to a positive integer.  For the deterministic
parser in C, this value must be a compile-time constant unless you are
assuming C99 or some other target language or compiler that allows
variable-length arrays.  The default is 200.

   Do not allow `YYINITDEPTH' to be greater than `YYMAXDEPTH'.

   Because of semantic differences between C and C++, the deterministic
parsers in C produced by Bison cannot grow when compiled by C++
compilers.  In this precise case (compiling a C parser as C++) you are
suggested to grow `YYINITDEPTH'.  The Bison maintainers hope to fix
this deficiency in a future release.

\1f
File: bison.info,  Node: Error Recovery,  Next: Context Dependency,  Prev: Algorithm,  Up: Top

6 Error Recovery
****************

It is not usually acceptable to have a program terminate on a syntax
error.  For example, a compiler should recover sufficiently to parse the
rest of the input file and check it for errors; a calculator should
accept another expression.

   In a simple interactive command parser where each input is one line,
it may be sufficient to allow `yyparse' to return 1 on error and have
the caller ignore the rest of the input line when that happens (and
then call `yyparse' again).  But this is inadequate for a compiler,
because it forgets all the syntactic context leading up to the error.
A syntax error deep within a function in the compiler input should not
cause the compiler to treat the following line like the beginning of a
source file.

   You can define how to recover from a syntax error by writing rules to
recognize the special token `error'.  This is a terminal symbol that is
always defined (you need not declare it) and reserved for error
handling.  The Bison parser generates an `error' token whenever a
syntax error happens; if you have provided a rule to recognize this
token in the current context, the parse can continue.

   For example:

     stmts:
       /* empty string */
     | stmts '\n'
     | stmts exp '\n'
     | stmts error '\n'

   The fourth rule in this example says that an error followed by a
newline makes a valid addition to any `stmts'.

   What happens if a syntax error occurs in the middle of an `exp'?  The
error recovery rule, interpreted strictly, applies to the precise
sequence of a `stmts', an `error' and a newline.  If an error occurs in
the middle of an `exp', there will probably be some additional tokens
and subexpressions on the stack after the last `stmts', and there will
be tokens to read before the next newline.  So the rule is not
applicable in the ordinary way.

   But Bison can force the situation to fit the rule, by discarding
part of the semantic context and part of the input.  First it discards
states and objects from the stack until it gets back to a state in
which the `error' token is acceptable.  (This means that the
subexpressions already parsed are discarded, back to the last complete
`stmts'.)  At this point the `error' token can be shifted.  Then, if
the old lookahead token is not acceptable to be shifted next, the
parser reads tokens and discards them until it finds a token which is
acceptable.  In this example, Bison reads and discards input until the
next newline so that the fourth rule can apply.  Note that discarded
symbols are possible sources of memory leaks, see *note Freeing
Discarded Symbols: Destructor Decl, for a means to reclaim this memory.

   The choice of error rules in the grammar is a choice of strategies
for error recovery.  A simple and useful strategy is simply to skip the
rest of the current input line or current statement if an error is
detected:

     stmt: error ';'  /* On error, skip until ';' is read.  */

   It is also useful to recover to the matching close-delimiter of an
opening-delimiter that has already been parsed.  Otherwise the
close-delimiter will probably appear to be unmatched, and generate
another, spurious error message:

     primary:
       '(' expr ')'
     | '(' error ')'
     ...
     ;

   Error recovery strategies are necessarily guesses.  When they guess
wrong, one syntax error often leads to another.  In the above example,
the error recovery rule guesses that an error is due to bad input
within one `stmt'.  Suppose that instead a spurious semicolon is
inserted in the middle of a valid `stmt'.  After the error recovery
rule recovers from the first error, another syntax error will be found
straightaway, since the text following the spurious semicolon is also
an invalid `stmt'.

   To prevent an outpouring of error messages, the parser will output
no error message for another syntax error that happens shortly after
the first; only after three consecutive input tokens have been
successfully shifted will error messages resume.

   Note that rules which accept the `error' token may have actions, just
as any other rules can.

   You can make error messages resume immediately by using the macro
`yyerrok' in an action.  If you do this in the error rule's action, no
error messages will be suppressed.  This macro requires no arguments;
`yyerrok;' is a valid C statement.

   The previous lookahead token is reanalyzed immediately after an
error.  If this is unacceptable, then the macro `yyclearin' may be used
to clear this token.  Write the statement `yyclearin;' in the error
rule's action.  *Note Special Features for Use in Actions: Action
Features.

   For example, suppose that on a syntax error, an error handling
routine is called that advances the input stream to some point where
parsing should once again commence.  The next symbol returned by the
lexical scanner is probably correct.  The previous lookahead token
ought to be discarded with `yyclearin;'.

   The expression `YYRECOVERING ()' yields 1 when the parser is
recovering from a syntax error, and 0 otherwise.  Syntax error
diagnostics are suppressed while recovering from a syntax error.

\1f
File: bison.info,  Node: Context Dependency,  Next: Debugging,  Prev: Error Recovery,  Up: Top

7 Handling Context Dependencies
*******************************

The Bison paradigm is to parse tokens first, then group them into larger
syntactic units.  In many languages, the meaning of a token is affected
by its context.  Although this violates the Bison paradigm, certain
techniques (known as "kludges") may enable you to write Bison parsers
for such languages.

* Menu:

* Semantic Tokens::   Token parsing can depend on the semantic context.
* Lexical Tie-ins::   Token parsing can depend on the syntactic context.
* Tie-in Recovery::   Lexical tie-ins have implications for how
                        error recovery rules must be written.

   (Actually, "kludge" means any technique that gets its job done but is
neither clean nor robust.)

\1f
File: bison.info,  Node: Semantic Tokens,  Next: Lexical Tie-ins,  Up: Context Dependency

7.1 Semantic Info in Token Types
================================

The C language has a context dependency: the way an identifier is used
depends on what its current meaning is.  For example, consider this:

     foo (x);

   This looks like a function call statement, but if `foo' is a typedef
name, then this is actually a declaration of `x'.  How can a Bison
parser for C decide how to parse this input?

   The method used in GNU C is to have two different token types,
`IDENTIFIER' and `TYPENAME'.  When `yylex' finds an identifier, it
looks up the current declaration of the identifier in order to decide
which token type to return: `TYPENAME' if the identifier is declared as
a typedef, `IDENTIFIER' otherwise.

   The grammar rules can then express the context dependency by the
choice of token type to recognize.  `IDENTIFIER' is accepted as an
expression, but `TYPENAME' is not.  `TYPENAME' can start a declaration,
but `IDENTIFIER' cannot.  In contexts where the meaning of the
identifier is _not_ significant, such as in declarations that can
shadow a typedef name, either `TYPENAME' or `IDENTIFIER' is
accepted--there is one rule for each of the two token types.

   This technique is simple to use if the decision of which kinds of
identifiers to allow is made at a place close to where the identifier is
parsed.  But in C this is not always so: C allows a declaration to
redeclare a typedef name provided an explicit type has been specified
earlier:

     typedef int foo, bar;
     int baz (void)
     {
       static bar (bar);      /* redeclare `bar' as static variable */
       extern foo foo (foo);  /* redeclare `foo' as function */
       return foo (bar);
     }

   Unfortunately, the name being declared is separated from the
declaration construct itself by a complicated syntactic structure--the
"declarator".

   As a result, part of the Bison parser for C needs to be duplicated,
with all the nonterminal names changed: once for parsing a declaration
in which a typedef name can be redefined, and once for parsing a
declaration in which that can't be done.  Here is a part of the
duplication, with actions omitted for brevity:

     initdcl:
       declarator maybeasm '=' init
     | declarator maybeasm
     ;

     notype_initdcl:
       notype_declarator maybeasm '=' init
     | notype_declarator maybeasm
     ;

Here `initdcl' can redeclare a typedef name, but `notype_initdcl'
cannot.  The distinction between `declarator' and `notype_declarator'
is the same sort of thing.

   There is some similarity between this technique and a lexical tie-in
(described next), in that information which alters the lexical analysis
is changed during parsing by other parts of the program.  The
difference is here the information is global, and is used for other
purposes in the program.  A true lexical tie-in has a special-purpose
flag controlled by the syntactic context.

\1f
File: bison.info,  Node: Lexical Tie-ins,  Next: Tie-in Recovery,  Prev: Semantic Tokens,  Up: Context Dependency

7.2 Lexical Tie-ins
===================

One way to handle context-dependency is the "lexical tie-in": a flag
which is set by Bison actions, whose purpose is to alter the way tokens
are parsed.

   For example, suppose we have a language vaguely like C, but with a
special construct `hex (HEX-EXPR)'.  After the keyword `hex' comes an
expression in parentheses in which all integers are hexadecimal.  In
particular, the token `a1b' must be treated as an integer rather than
as an identifier if it appears in that context.  Here is how you can do
it:

     %{
       int hexflag;
       int yylex (void);
       void yyerror (char const *);
     %}
     %%
     ...
     expr:
       IDENTIFIER
     | constant
     | HEX '('        { hexflag = 1; }
         expr ')'     { hexflag = 0; $$ = $4; }
     | expr '+' expr  { $$ = make_sum ($1, $3); }
     ...
     ;

     constant:
       INTEGER
     | STRING
     ;

Here we assume that `yylex' looks at the value of `hexflag'; when it is
nonzero, all integers are parsed in hexadecimal, and tokens starting
with letters are parsed as integers if possible.

   The declaration of `hexflag' shown in the prologue of the grammar
file is needed to make it accessible to the actions (*note The
Prologue: Prologue.).  You must also write the code in `yylex' to obey
the flag.

\1f
File: bison.info,  Node: Tie-in Recovery,  Prev: Lexical Tie-ins,  Up: Context Dependency

7.3 Lexical Tie-ins and Error Recovery
======================================

Lexical tie-ins make strict demands on any error recovery rules you
have.  *Note Error Recovery::.

   The reason for this is that the purpose of an error recovery rule is
to abort the parsing of one construct and resume in some larger
construct.  For example, in C-like languages, a typical error recovery
rule is to skip tokens until the next semicolon, and then start a new
statement, like this:

     stmt:
       expr ';'
     | IF '(' expr ')' stmt { ... }
     ...
     | error ';'  { hexflag = 0; }
     ;

   If there is a syntax error in the middle of a `hex (EXPR)'
construct, this error rule will apply, and then the action for the
completed `hex (EXPR)' will never run.  So `hexflag' would remain set
for the entire rest of the input, or until the next `hex' keyword,
causing identifiers to be misinterpreted as integers.

   To avoid this problem the error recovery rule itself clears
`hexflag'.

   There may also be an error recovery rule that works within
expressions.  For example, there could be a rule which applies within
parentheses and skips to the close-parenthesis:

     expr:
       ...
     | '(' expr ')'   { $$ = $2; }
     | '(' error ')'
     ...

   If this rule acts within the `hex' construct, it is not going to
abort that construct (since it applies to an inner level of parentheses
within the construct).  Therefore, it should not clear the flag: the
rest of the `hex' construct should be parsed with the flag still in
effect.

   What if there is an error recovery rule which might abort out of the
`hex' construct or might not, depending on circumstances?  There is no
way you can write the action to determine whether a `hex' construct is
being aborted or not.  So if you are using a lexical tie-in, you had
better make sure your error recovery rules are not of this kind.  Each
rule must be such that you can be sure that it always will, or always
won't, have to clear the flag.

\1f
File: bison.info,  Node: Debugging,  Next: Invocation,  Prev: Context Dependency,  Up: Top

8 Debugging Your Parser
***********************

Developing a parser can be a challenge, especially if you don't
understand the algorithm (*note The Bison Parser Algorithm:
Algorithm.).  This chapter explains how to generate and read the
detailed description of the automaton, and how to enable and understand
the parser run-time traces.

* Menu:

* Understanding::     Understanding the structure of your parser.
* Tracing::           Tracing the execution of your parser.

\1f
File: bison.info,  Node: Understanding,  Next: Tracing,  Up: Debugging

8.1 Understanding Your Parser
=============================

As documented elsewhere (*note The Bison Parser Algorithm: Algorithm.)
Bison parsers are "shift/reduce automata".  In some cases (much more
frequent than one would hope), looking at this automaton is required to
tune or simply fix a parser.  Bison provides two different
representation of it, either textually or graphically (as a DOT file).

   The textual file is generated when the options `--report' or
`--verbose' are specified, see *note Invoking Bison: Invocation.  Its
name is made by removing `.tab.c' or `.c' from the parser
implementation file name, and adding `.output' instead.  Therefore, if
the grammar file is `foo.y', then the parser implementation file is
called `foo.tab.c' by default.  As a consequence, the verbose output
file is called `foo.output'.

   The following grammar file, `calc.y', will be used in the sequel:

     %token NUM STR
     %left '+' '-'
     %left '*'
     %%
     exp:
       exp '+' exp
     | exp '-' exp
     | exp '*' exp
     | exp '/' exp
     | NUM
     ;
     useless: STR;
     %%

   `bison' reports:

     calc.y: warning: 1 nonterminal useless in grammar
     calc.y: warning: 1 rule useless in grammar
     calc.y:11.1-7: warning: nonterminal useless in grammar: useless
     calc.y:11.10-12: warning: rule useless in grammar: useless: STR
     calc.y: conflicts: 7 shift/reduce

   When given `--report=state', in addition to `calc.tab.c', it creates
a file `calc.output' with contents detailed below.  The order of the
output and the exact presentation might vary, but the interpretation is
the same.

The first section reports useless tokens, nonterminals and rules.
Useless nonterminals and rules are removed in order to produce a
smaller parser, but useless tokens are preserved, since they might be
used by the scanner (note the difference between "useless" and "unused"
below):

     Nonterminals useless in grammar
        useless

     Terminals unused in grammar
        STR

     Rules useless in grammar
         6 useless: STR

The next section lists states that still have conflicts.

     State 8 conflicts: 1 shift/reduce
     State 9 conflicts: 1 shift/reduce
     State 10 conflicts: 1 shift/reduce
     State 11 conflicts: 4 shift/reduce

Then Bison reproduces the exact grammar it used:

     Grammar

         0 $accept: exp $end

         1 exp: exp '+' exp
         2    | exp '-' exp
         3    | exp '*' exp
         4    | exp '/' exp
         5    | NUM

and reports the uses of the symbols:

     Terminals, with rules where they appear

     $end (0) 0
     '*' (42) 3
     '+' (43) 1
     '-' (45) 2
     '/' (47) 4
     error (256)
     NUM (258) 5
     STR (259)

     Nonterminals, with rules where they appear

     $accept (9)
         on left: 0
     exp (10)
         on left: 1 2 3 4 5, on right: 0 1 2 3 4

Bison then proceeds onto the automaton itself, describing each state
with its set of "items", also known as "pointed rules".  Each item is a
production rule together with a point (`.') marking the location of the
input cursor.

     state 0

         0 $accept: . exp $end

         NUM  shift, and go to state 1

         exp  go to state 2

   This reads as follows: "state 0 corresponds to being at the very
beginning of the parsing, in the initial rule, right before the start
symbol (here, `exp').  When the parser returns to this state right
after having reduced a rule that produced an `exp', the control flow
jumps to state 2.  If there is no such transition on a nonterminal
symbol, and the lookahead is a `NUM', then this token is shifted onto
the parse stack, and the control flow jumps to state 1.  Any other
lookahead triggers a syntax error."

   Even though the only active rule in state 0 seems to be rule 0, the
report lists `NUM' as a lookahead token because `NUM' can be at the
beginning of any rule deriving an `exp'.  By default Bison reports the
so-called "core" or "kernel" of the item set, but if you want to see
more detail you can invoke `bison' with `--report=itemset' to list the
derived items as well:

     state 0

         0 $accept: . exp $end
         1 exp: . exp '+' exp
         2    | . exp '-' exp
         3    | . exp '*' exp
         4    | . exp '/' exp
         5    | . NUM

         NUM  shift, and go to state 1

         exp  go to state 2

In the state 1...

     state 1

         5 exp: NUM .

         $default  reduce using rule 5 (exp)

the rule 5, `exp: NUM;', is completed.  Whatever the lookahead token
(`$default'), the parser will reduce it.  If it was coming from state
0, then, after this reduction it will return to state 0, and will jump
to state 2 (`exp: go to state 2').

     state 2

         0 $accept: exp . $end
         1 exp: exp . '+' exp
         2    | exp . '-' exp
         3    | exp . '*' exp
         4    | exp . '/' exp

         $end  shift, and go to state 3
         '+'   shift, and go to state 4
         '-'   shift, and go to state 5
         '*'   shift, and go to state 6
         '/'   shift, and go to state 7

In state 2, the automaton can only shift a symbol.  For instance,
because of the item `exp: exp . '+' exp', if the lookahead is `+' it is
shifted onto the parse stack, and the automaton jumps to state 4,
corresponding to the item `exp: exp '+' . exp'.  Since there is no
default action, any lookahead not listed triggers a syntax error.

   The state 3 is named the "final state", or the "accepting state":

     state 3

         0 $accept: exp $end .

         $default  accept

the initial rule is completed (the start symbol and the end-of-input
were read), the parsing exits successfully.

   The interpretation of states 4 to 7 is straightforward, and is left
to the reader.

     state 4

         1 exp: exp '+' . exp

         NUM  shift, and go to state 1

         exp  go to state 8


     state 5

         2 exp: exp '-' . exp

         NUM  shift, and go to state 1

         exp  go to state 9


     state 6

         3 exp: exp '*' . exp

         NUM  shift, and go to state 1

         exp  go to state 10


     state 7

         4 exp: exp '/' . exp

         NUM  shift, and go to state 1

         exp  go to state 11

   As was announced in beginning of the report, `State 8 conflicts: 1
shift/reduce':

     state 8

         1 exp: exp . '+' exp
         1    | exp '+' exp .
         2    | exp . '-' exp
         3    | exp . '*' exp
         4    | exp . '/' exp

         '*'  shift, and go to state 6
         '/'  shift, and go to state 7

         '/'       [reduce using rule 1 (exp)]
         $default  reduce using rule 1 (exp)

   Indeed, there are two actions associated to the lookahead `/':
either shifting (and going to state 7), or reducing rule 1.  The
conflict means that either the grammar is ambiguous, or the parser lacks
information to make the right decision.  Indeed the grammar is
ambiguous, as, since we did not specify the precedence of `/', the
sentence `NUM + NUM / NUM' can be parsed as `NUM + (NUM / NUM)', which
corresponds to shifting `/', or as `(NUM + NUM) / NUM', which
corresponds to reducing rule 1.

   Because in deterministic parsing a single decision can be made, Bison
arbitrarily chose to disable the reduction, see *note Shift/Reduce
Conflicts: Shift/Reduce.  Discarded actions are reported between square
brackets.

   Note that all the previous states had a single possible action:
either shifting the next token and going to the corresponding state, or
reducing a single rule.  In the other cases, i.e., when shifting _and_
reducing is possible or when _several_ reductions are possible, the
lookahead is required to select the action.  State 8 is one such state:
if the lookahead is `*' or `/' then the action is shifting, otherwise
the action is reducing rule 1.  In other words, the first two items,
corresponding to rule 1, are not eligible when the lookahead token is
`*', since we specified that `*' has higher precedence than `+'.  More
generally, some items are eligible only with some set of possible
lookahead tokens.  When run with `--report=lookahead', Bison specifies
these lookahead tokens:

     state 8

         1 exp: exp . '+' exp
         1    | exp '+' exp .  [$end, '+', '-', '/']
         2    | exp . '-' exp
         3    | exp . '*' exp
         4    | exp . '/' exp

         '*'  shift, and go to state 6
         '/'  shift, and go to state 7

         '/'       [reduce using rule 1 (exp)]
         $default  reduce using rule 1 (exp)

   Note however that while `NUM + NUM / NUM' is ambiguous (which
results in the conflicts on `/'), `NUM + NUM * NUM' is not: the
conflict was solved thanks to associativity and precedence directives.
If invoked with `--report=solved', Bison includes information about the
solved conflicts in the report:

     Conflict between rule 1 and token '+' resolved as reduce (%left '+').
     Conflict between rule 1 and token '-' resolved as reduce (%left '-').
     Conflict between rule 1 and token '*' resolved as shift ('+' < '*').

   The remaining states are similar:

     state 9

         1 exp: exp . '+' exp
         2    | exp . '-' exp
         2    | exp '-' exp .
         3    | exp . '*' exp
         4    | exp . '/' exp

         '*'  shift, and go to state 6
         '/'  shift, and go to state 7

         '/'       [reduce using rule 2 (exp)]
         $default  reduce using rule 2 (exp)

     state 10

         1 exp: exp . '+' exp
         2    | exp . '-' exp
         3    | exp . '*' exp
         3    | exp '*' exp .
         4    | exp . '/' exp

         '/'  shift, and go to state 7

         '/'       [reduce using rule 3 (exp)]
         $default  reduce using rule 3 (exp)

     state 11

         1 exp: exp . '+' exp
         2    | exp . '-' exp
         3    | exp . '*' exp
         4    | exp . '/' exp
         4    | exp '/' exp .

         '+'  shift, and go to state 4
         '-'  shift, and go to state 5
         '*'  shift, and go to state 6
         '/'  shift, and go to state 7

         '+'       [reduce using rule 4 (exp)]
         '-'       [reduce using rule 4 (exp)]
         '*'       [reduce using rule 4 (exp)]
         '/'       [reduce using rule 4 (exp)]
         $default  reduce using rule 4 (exp)

Observe that state 11 contains conflicts not only due to the lack of
precedence of `/' with respect to `+', `-', and `*', but also because
the associativity of `/' is not specified.

\1f
File: bison.info,  Node: Tracing,  Prev: Understanding,  Up: Debugging

8.2 Tracing Your Parser
=======================

When a Bison grammar compiles properly but parses "incorrectly", the
`yydebug' parser-trace feature helps figuring out why.

* Menu:

* Enabling Traces::    Activating run-time trace support
* Mfcalc Traces::      Extending `mfcalc' to support traces
* The YYPRINT Macro::  Obsolete interface for semantic value reports

\1f
File: bison.info,  Node: Enabling Traces,  Next: Mfcalc Traces,  Up: Tracing

8.2.1 Enabling Traces
---------------------

There are several means to enable compilation of trace facilities:

the macro `YYDEBUG'
     Define the macro `YYDEBUG' to a nonzero value when you compile the
     parser.  This is compliant with POSIX Yacc.  You could use
     `-DYYDEBUG=1' as a compiler option or you could put `#define
     YYDEBUG 1' in the prologue of the grammar file (*note The
     Prologue: Prologue.).

     If the `%define' variable `api.prefix' is used (*note Multiple
     Parsers in the Same Program: Multiple Parsers.), for instance
     `%define api.prefix x', then if `CDEBUG' is defined, its value
     controls the tracing feature (enabled iff nonzero); otherwise
     tracing is enabled iff `YYDEBUG' is nonzero.

the option `-t' (POSIX Yacc compliant)
the option `--debug' (Bison extension)
     Use the `-t' option when you run Bison (*note Invoking Bison:
     Invocation.).  With `%define api.prefix c', it defines `CDEBUG' to
     1, otherwise it defines `YYDEBUG' to 1.

the directive `%debug'
     Add the `%debug' directive (*note Bison Declaration Summary: Decl
     Summary.).  This is a Bison extension, especially useful for
     languages that don't use a preprocessor.  Unless POSIX and Yacc
     portability matter to you, this is the preferred solution.

   We suggest that you always enable the debug option so that debugging
is always possible.

   The trace facility outputs messages with macro calls of the form
`YYFPRINTF (stderr, FORMAT, ARGS)' where FORMAT and ARGS are the usual
`printf' format and variadic arguments.  If you define `YYDEBUG' to a
nonzero value but do not define `YYFPRINTF', `<stdio.h>' is
automatically included and `YYFPRINTF' is defined to `fprintf'.

   Once you have compiled the program with trace facilities, the way to
request a trace is to store a nonzero value in the variable `yydebug'.
You can do this by making the C code do it (in `main', perhaps), or you
can alter the value with a C debugger.

   Each step taken by the parser when `yydebug' is nonzero produces a
line or two of trace information, written on `stderr'.  The trace
messages tell you these things:

   * Each time the parser calls `yylex', what kind of token was read.

   * Each time a token is shifted, the depth and complete contents of
     the state stack (*note Parser States::).

   * Each time a rule is reduced, which rule it is, and the complete
     contents of the state stack afterward.

   To make sense of this information, it helps to refer to the automaton
description file (*note Understanding Your Parser: Understanding.).
This file shows the meaning of each state in terms of positions in
various rules, and also what each state will do with each possible
input token.  As you read the successive trace messages, you can see
that the parser is functioning according to its specification in the
listing file.  Eventually you will arrive at the place where something
undesirable happens, and you will see which parts of the grammar are to
blame.

   The parser implementation file is a C/C++/Java program and you can
use debuggers on it, but it's not easy to interpret what it is doing.
The parser function is a finite-state machine interpreter, and aside
from the actions it executes the same code over and over.  Only the
values of variables show where in the grammar it is working.

\1f
File: bison.info,  Node: Mfcalc Traces,  Next: The YYPRINT Macro,  Prev: Enabling Traces,  Up: Tracing

8.2.2 Enabling Debug Traces for `mfcalc'
----------------------------------------

The debugging information normally gives the token type of each token
read, but not its semantic value.  The `%printer' directive allows
specify how semantic values are reported, see *note Printing Semantic
Values: Printer Decl.  For backward compatibility, Yacc like C parsers
may also use the `YYPRINT' (*note The `YYPRINT' Macro: The YYPRINT
Macro.), but its use is discouraged.

   As a demonstration of `%printer', consider the multi-function
calculator, `mfcalc' (*note Multi-function Calc::).  To enable run-time
traces, and semantic value reports, insert the following directives in
its prologue:

     /* Generate the parser description file.  */
     %verbose
     /* Enable run-time traces (yydebug).  */
     %define parse.trace

     /* Formatting semantic values.  */
     %printer { fprintf (yyoutput, "%s", $$->name); } VAR;
     %printer { fprintf (yyoutput, "%s()", $$->name); } FNCT;
     %printer { fprintf (yyoutput, "%g", $$); } <val>;

   The `%define' directive instructs Bison to generate run-time trace
support.  Then, activation of these traces is controlled at run-time by
the `yydebug' variable, which is disabled by default.  Because these
traces will refer to the "states" of the parser, it is helpful to ask
for the creation of a description of that parser; this is the purpose
of (admittedly ill-named) `%verbose' directive.

   The set of `%printer' directives demonstrates how to format the
semantic value in the traces.  Note that the specification can be done
either on the symbol type (e.g., `VAR' or `FNCT'), or on the type tag:
since `<val>' is the type for both `NUM' and `exp', this printer will
be used for them.

   Here is a sample of the information provided by run-time traces.
The traces are sent onto standard error.

     $ echo 'sin(1-1)' | ./mfcalc -p
     Starting parse
     Entering state 0
     Reducing stack by rule 1 (line 34):
     -> $$ = nterm input ()
     Stack now 0
     Entering state 1

This first batch shows a specific feature of this grammar: the first
rule (which is in line 34 of `mfcalc.y' can be reduced without even
having to look for the first token.  The resulting left-hand symbol
(`$$') is a valueless (`()') `input' non terminal (`nterm').

   Then the parser calls the scanner.
     Reading a token: Next token is token FNCT (sin())
     Shifting token FNCT (sin())
     Entering state 6

That token (`token') is a function (`FNCT') whose value is `sin' as
formatted per our `%printer' specification: `sin()'.  The parser stores
(`Shifting') that token, and others, until it can do something about it.

     Reading a token: Next token is token '(' ()
     Shifting token '(' ()
     Entering state 14
     Reading a token: Next token is token NUM (1.000000)
     Shifting token NUM (1.000000)
     Entering state 4
     Reducing stack by rule 6 (line 44):
        $1 = token NUM (1.000000)
     -> $$ = nterm exp (1.000000)
     Stack now 0 1 6 14
     Entering state 24

The previous reduction demonstrates the `%printer' directive for
`<val>': both the token `NUM' and the resulting non-terminal `exp' have
`1' as value.

     Reading a token: Next token is token '-' ()
     Shifting token '-' ()
     Entering state 17
     Reading a token: Next token is token NUM (1.000000)
     Shifting token NUM (1.000000)
     Entering state 4
     Reducing stack by rule 6 (line 44):
        $1 = token NUM (1.000000)
     -> $$ = nterm exp (1.000000)
     Stack now 0 1 6 14 24 17
     Entering state 26
     Reading a token: Next token is token ')' ()
     Reducing stack by rule 11 (line 49):
        $1 = nterm exp (1.000000)
        $2 = token '-' ()
        $3 = nterm exp (1.000000)
     -> $$ = nterm exp (0.000000)
     Stack now 0 1 6 14
     Entering state 24

The rule for the subtraction was just reduced.  The parser is about to
discover the end of the call to `sin'.

     Next token is token ')' ()
     Shifting token ')' ()
     Entering state 31
     Reducing stack by rule 9 (line 47):
        $1 = token FNCT (sin())
        $2 = token '(' ()
        $3 = nterm exp (0.000000)
        $4 = token ')' ()
     -> $$ = nterm exp (0.000000)
     Stack now 0 1
     Entering state 11

Finally, the end-of-line allow the parser to complete the computation,
and display its result.

     Reading a token: Next token is token '\n' ()
     Shifting token '\n' ()
     Entering state 22
     Reducing stack by rule 4 (line 40):
        $1 = nterm exp (0.000000)
        $2 = token '\n' ()
     => 0
     -> $$ = nterm line ()
     Stack now 0 1
     Entering state 10
     Reducing stack by rule 2 (line 35):
        $1 = nterm input ()
        $2 = nterm line ()
     -> $$ = nterm input ()
     Stack now 0
     Entering state 1

   The parser has returned into state 1, in which it is waiting for the
next expression to evaluate, or for the end-of-file token, which causes
the completion of the parsing.

     Reading a token: Now at end of input.
     Shifting token $end ()
     Entering state 2
     Stack now 0 1 2
     Cleanup: popping token $end ()
     Cleanup: popping nterm input ()

\1f
File: bison.info,  Node: The YYPRINT Macro,  Prev: Mfcalc Traces,  Up: Tracing

8.2.3 The `YYPRINT' Macro
-------------------------

Before `%printer' support, semantic values could be displayed using the
`YYPRINT' macro, which works only for terminal symbols and only with
the `yacc.c' skeleton.

 -- Macro: YYPRINT (STREAM, TOKEN, VALUE);
     If you define `YYPRINT', it should take three arguments.  The
     parser will pass a standard I/O stream, the numeric code for the
     token type, and the token value (from `yylval').

     For `yacc.c' only.  Obsoleted by `%printer'.

   Here is an example of `YYPRINT' suitable for the multi-function
calculator (*note Declarations for `mfcalc': Mfcalc Declarations.):

     %{
       static void print_token_value (FILE *, int, YYSTYPE);
       #define YYPRINT(File, Type, Value)            \
         print_token_value (File, Type, Value)
     %}

     ... %% ... %% ...

     static void
     print_token_value (FILE *file, int type, YYSTYPE value)
     {
       if (type == VAR)
         fprintf (file, "%s", value.tptr->name);
       else if (type == NUM)
         fprintf (file, "%d", value.val);
     }

\1f
File: bison.info,  Node: Invocation,  Next: Other Languages,  Prev: Debugging,  Up: Top

9 Invoking Bison
****************

The usual way to invoke Bison is as follows:

     bison INFILE

   Here INFILE is the grammar file name, which usually ends in `.y'.
The parser implementation file's name is made by replacing the `.y'
with `.tab.c' and removing any leading directory.  Thus, the `bison
foo.y' file name yields `foo.tab.c', and the `bison hack/foo.y' file
name yields `foo.tab.c'.  It's also possible, in case you are writing
C++ code instead of C in your grammar file, to name it `foo.ypp' or
`foo.y++'.  Then, the output files will take an extension like the
given one as input (respectively `foo.tab.cpp' and `foo.tab.c++').  This
feature takes effect with all options that manipulate file names like
`-o' or `-d'.

   For example :

     bison -d INFILE.YXX
   will produce `infile.tab.cxx' and `infile.tab.hxx', and

     bison -d -o OUTPUT.C++ INFILE.Y
   will produce `output.c++' and `outfile.h++'.

   For compatibility with POSIX, the standard Bison distribution also
contains a shell script called `yacc' that invokes Bison with the `-y'
option.

* Menu:

* Bison Options::     All the options described in detail,
                        in alphabetical order by short options.
* Option Cross Key::  Alphabetical list of long options.
* Yacc Library::      Yacc-compatible `yylex' and `main'.

\1f
File: bison.info,  Node: Bison Options,  Next: Option Cross Key,  Up: Invocation

9.1 Bison Options
=================

Bison supports both traditional single-letter options and mnemonic long
option names.  Long option names are indicated with `--' instead of
`-'.  Abbreviations for option names are allowed as long as they are
unique.  When a long option takes an argument, like `--file-prefix',
connect the option name and the argument with `='.

   Here is a list of options that can be used with Bison, alphabetized
by short option.  It is followed by a cross key alphabetized by long
option.

Operations modes:
`-h'
`--help'
     Print a summary of the command-line options to Bison and exit.

`-V'
`--version'
     Print the version number of Bison and exit.

`--print-localedir'
     Print the name of the directory containing locale-dependent data.

`--print-datadir'
     Print the name of the directory containing skeletons and XSLT.

`-y'
`--yacc'
     Act more like the traditional Yacc command.  This can cause
     different diagnostics to be generated, and may change behavior in
     other minor ways.  Most importantly, imitate Yacc's output file
     name conventions, so that the parser implementation file is called
     `y.tab.c', and the other outputs are called `y.output' and
     `y.tab.h'.  Also, if generating a deterministic parser in C,
     generate `#define' statements in addition to an `enum' to associate
     token numbers with token names.  Thus, the following shell script
     can substitute for Yacc, and the Bison distribution contains such
     a script for compatibility with POSIX:

          #! /bin/sh
          bison -y "$@"

     The `-y'/`--yacc' option is intended for use with traditional Yacc
     grammars.  If your grammar uses a Bison extension like
     `%glr-parser', Bison might not be Yacc-compatible even if this
     option is specified.

`-W [CATEGORY]'
`--warnings[=CATEGORY]'
     Output warnings falling in CATEGORY.  CATEGORY can be one of:
    `midrule-values'
          Warn about mid-rule values that are set but not used within
          any of the actions of the parent rule.  For example, warn
          about unused `$2' in:

               exp: '1' { $$ = 1; } '+' exp { $$ = $1 + $4; };

          Also warn about mid-rule values that are used but not set.
          For example, warn about unset `$$' in the mid-rule action in:

               exp: '1' { $1 = 1; } '+' exp { $$ = $2 + $4; };

          These warnings are not enabled by default since they
          sometimes prove to be false alarms in existing grammars
          employing the Yacc constructs `$0' or `$-N' (where N is some
          positive integer).

    `yacc'
          Incompatibilities with POSIX Yacc.

    `conflicts-sr'
    `conflicts-rr'
          S/R and R/R conflicts.  These warnings are enabled by
          default.  However, if the `%expect' or `%expect-rr' directive
          is specified, an unexpected number of conflicts is an error,
          and an expected number of conflicts is not reported, so `-W'
          and `--warning' then have no effect on the conflict report.

    `other'
          All warnings not categorized above.  These warnings are
          enabled by default.

          This category is provided merely for the sake of
          completeness.  Future releases of Bison may move warnings
          from this category to new, more specific categories.

    `all'
          All the warnings.

    `none'
          Turn off all the warnings.

    `error'
          Treat warnings as errors.

     A category can be turned off by prefixing its name with `no-'.  For
     instance, `-Wno-yacc' will hide the warnings about POSIX Yacc
     incompatibilities.

Tuning the parser:

`-t'
`--debug'
     In the parser implementation file, define the macro `YYDEBUG' to 1
     if it is not already defined, so that the debugging facilities are
     compiled.  *Note Tracing Your Parser: Tracing.

`-D NAME[=VALUE]'
`--define=NAME[=VALUE]'
`-F NAME[=VALUE]'
`--force-define=NAME[=VALUE]'
     Each of these is equivalent to `%define NAME "VALUE"' (*note
     %define Summary::) except that Bison processes multiple
     definitions for the same NAME as follows:

        * Bison quietly ignores all command-line definitions for NAME
          except the last.

        * If that command-line definition is specified by a `-D' or
          `--define', Bison reports an error for any `%define'
          definition for NAME.

        * If that command-line definition is specified by a `-F' or
          `--force-define' instead, Bison quietly ignores all `%define'
          definitions for NAME.

        * Otherwise, Bison reports an error if there are multiple
          `%define' definitions for NAME.

     You should avoid using `-F' and `--force-define' in your make
     files unless you are confident that it is safe to quietly ignore
     any conflicting `%define' that may be added to the grammar file.

`-L LANGUAGE'
`--language=LANGUAGE'
     Specify the programming language for the generated parser, as if
     `%language' was specified (*note Bison Declaration Summary: Decl
     Summary.).  Currently supported languages include C, C++, and Java.
     LANGUAGE is case-insensitive.

     This option is experimental and its effect may be modified in
     future releases.

`--locations'
     Pretend that `%locations' was specified.  *Note Decl Summary::.

`-p PREFIX'
`--name-prefix=PREFIX'
     Pretend that `%name-prefix "PREFIX"' was specified (*note Decl
     Summary::).  Obsoleted by `-Dapi.prefix=PREFIX'.  *Note Multiple
     Parsers in the Same Program: Multiple Parsers.

`-l'
`--no-lines'
     Don't put any `#line' preprocessor commands in the parser
     implementation file.  Ordinarily Bison puts them in the parser
     implementation file so that the C compiler and debuggers will
     associate errors with your source file, the grammar file.  This
     option causes them to associate errors with the parser
     implementation file, treating it as an independent source file in
     its own right.

`-S FILE'
`--skeleton=FILE'
     Specify the skeleton to use, similar to `%skeleton' (*note Bison
     Declaration Summary: Decl Summary.).

     If FILE does not contain a `/', FILE is the name of a skeleton
     file in the Bison installation directory.  If it does, FILE is an
     absolute file name or a file name relative to the current working
     directory.  This is similar to how most shells resolve commands.

`-k'
`--token-table'
     Pretend that `%token-table' was specified.  *Note Decl Summary::.

Adjust the output:

`--defines[=FILE]'
     Pretend that `%defines' was specified, i.e., write an extra output
     file containing macro definitions for the token type names defined
     in the grammar, as well as a few other declarations.  *Note Decl
     Summary::.

`-d'
     This is the same as `--defines' except `-d' does not accept a FILE
     argument since POSIX Yacc requires that `-d' can be bundled with
     other short options.

`-b FILE-PREFIX'
`--file-prefix=PREFIX'
     Pretend that `%file-prefix' was specified, i.e., specify prefix to
     use for all Bison output file names.  *Note Decl Summary::.

`-r THINGS'
`--report=THINGS'
     Write an extra output file containing verbose description of the
     comma separated list of THINGS among:

    `state'
          Description of the grammar, conflicts (resolved and
          unresolved), and parser's automaton.

    `lookahead'
          Implies `state' and augments the description of the automaton
          with each rule's lookahead set.

    `itemset'
          Implies `state' and augments the description of the automaton
          with the full set of items for each state, instead of its
          core only.

`--report-file=FILE'
     Specify the FILE for the verbose description.

`-v'
`--verbose'
     Pretend that `%verbose' was specified, i.e., write an extra output
     file containing verbose descriptions of the grammar and parser.
     *Note Decl Summary::.

`-o FILE'
`--output=FILE'
     Specify the FILE for the parser implementation file.

     The other output files' names are constructed from FILE as
     described under the `-v' and `-d' options.

`-g [FILE]'
`--graph[=FILE]'
     Output a graphical representation of the parser's automaton
     computed by Bison, in Graphviz (http://www.graphviz.org/) DOT
     (http://www.graphviz.org/doc/info/lang.html) format.  `FILE' is
     optional.  If omitted and the grammar file is `foo.y', the output
     file will be `foo.dot'.

`-x [FILE]'
`--xml[=FILE]'
     Output an XML report of the parser's automaton computed by Bison.
     `FILE' is optional.  If omitted and the grammar file is `foo.y',
     the output file will be `foo.xml'.  (The current XML schema is
     experimental and may evolve.  More user feedback will help to
     stabilize it.)

\1f
File: bison.info,  Node: Option Cross Key,  Next: Yacc Library,  Prev: Bison Options,  Up: Invocation

9.2 Option Cross Key
====================

Here is a list of options, alphabetized by long option, to help you find
the corresponding short option and directive.

Long Option                     Short Option        Bison Directive
--------------------------------------------------------------------------------- 
`--debug'                       `-t'                `%debug'
`--define=NAME[=VALUE]'         `-D NAME[=VALUE]'   `%define NAME ["VALUE"]'
`--defines[=FILE]'              `-d'                `%defines ["FILE"]'
`--file-prefix=PREFIX'          `-b PREFIX'         `%file-prefix "PREFIX"'
`--force-define=NAME[=VALUE]'   `-F NAME[=VALUE]'   `%define NAME ["VALUE"]'
`--graph[=FILE]'                `-g [FILE]'         
`--help'                        `-h'                
`--language=LANGUAGE'           `-L LANGUAGE'       `%language "LANGUAGE"'
`--locations'                                       `%locations'
`--name-prefix=PREFIX'          `-p PREFIX'         `%name-prefix "PREFIX"'
`--no-lines'                    `-l'                `%no-lines'
`--output=FILE'                 `-o FILE'           `%output "FILE"'
`--print-datadir'                                   
`--print-localedir'                                 
`--report-file=FILE'                                
`--report=THINGS'               `-r THINGS'         
`--skeleton=FILE'               `-S FILE'           `%skeleton "FILE"'
`--token-table'                 `-k'                `%token-table'
`--verbose'                     `-v'                `%verbose'
`--version'                     `-V'                
`--warnings[=CATEGORY]'         `-W [CATEGORY]'     
`--xml[=FILE]'                  `-x [FILE]'         
`--yacc'                        `-y'                `%yacc'

\1f
File: bison.info,  Node: Yacc Library,  Prev: Option Cross Key,  Up: Invocation

9.3 Yacc Library
================

The Yacc library contains default implementations of the `yyerror' and
`main' functions.  These default implementations are normally not
useful, but POSIX requires them.  To use the Yacc library, link your
program with the `-ly' option.  Note that Bison's implementation of the
Yacc library is distributed under the terms of the GNU General Public
License (*note Copying::).

   If you use the Yacc library's `yyerror' function, you should declare
`yyerror' as follows:

     int yyerror (char const *);

   Bison ignores the `int' value returned by this `yyerror'.  If you
use the Yacc library's `main' function, your `yyparse' function should
have the following type signature:

     int yyparse (void);

\1f
File: bison.info,  Node: Other Languages,  Next: FAQ,  Prev: Invocation,  Up: Top

10 Parsers Written In Other Languages
*************************************

* Menu:

* C++ Parsers::                 The interface to generate C++ parser classes
* Java Parsers::                The interface to generate Java parser classes

\1f
File: bison.info,  Node: C++ Parsers,  Next: Java Parsers,  Up: Other Languages

10.1 C++ Parsers
================

* Menu:

* C++ Bison Interface::         Asking for C++ parser generation
* C++ Semantic Values::         %union vs. C++
* C++ Location Values::         The position and location classes
* C++ Parser Interface::        Instantiating and running the parser
* C++ Scanner Interface::       Exchanges between yylex and parse
* A Complete C++ Example::      Demonstrating their use

\1f
File: bison.info,  Node: C++ Bison Interface,  Next: C++ Semantic Values,  Up: C++ Parsers

10.1.1 C++ Bison Interface
--------------------------

The C++ deterministic parser is selected using the skeleton directive,
`%skeleton "lalr1.cc"', or the synonymous command-line option
`--skeleton=lalr1.cc'.  *Note Decl Summary::.

   When run, `bison' will create several entities in the `yy' namespace.  Use
the `%define namespace' directive to change the namespace name, see
*note namespace: %define Summary.  The various classes are generated in
the following files:

`position.hh'
`location.hh'
     The definition of the classes `position' and `location', used for
     location tracking.  *Note C++ Location Values::.

`stack.hh'
     An auxiliary class `stack' used by the parser.

`FILE.hh'
`FILE.cc'
     (Assuming the extension of the grammar file was `.yy'.)  The
     declaration and implementation of the C++ parser class.  The
     basename and extension of these two files follow the same rules as
     with regular C parsers (*note Invocation::).

     The header is _mandatory_; you must either pass `-d'/`--defines'
     to `bison', or use the `%defines' directive.

   All these files are documented using Doxygen; run `doxygen' for a
complete and accurate documentation.

\1f
File: bison.info,  Node: C++ Semantic Values,  Next: C++ Location Values,  Prev: C++ Bison Interface,  Up: C++ Parsers

10.1.2 C++ Semantic Values
--------------------------

The `%union' directive works as for C, see *note The Collection of
Value Types: Union Decl.  In particular it produces a genuine
`union'(1), which have a few specific features in C++.
   - The type `YYSTYPE' is defined but its use is discouraged: rather
     you should refer to the parser's encapsulated type
     `yy::parser::semantic_type'.

   - Non POD (Plain Old Data) types cannot be used.  C++ forbids any
     instance of classes with constructors in unions: only _pointers_
     to such objects are allowed.

   Because objects have to be stored via pointers, memory is not
reclaimed automatically: using the `%destructor' directive is the only
means to avoid leaks.  *Note Freeing Discarded Symbols: Destructor Decl.

   ---------- Footnotes ----------

   (1) In the future techniques to allow complex types within
pseudo-unions (similar to Boost variants) might be implemented to
alleviate these issues.

\1f
File: bison.info,  Node: C++ Location Values,  Next: C++ Parser Interface,  Prev: C++ Semantic Values,  Up: C++ Parsers

10.1.3 C++ Location Values
--------------------------

When the directive `%locations' is used, the C++ parser supports
location tracking, see *note Tracking Locations::.  Two auxiliary
classes define a `position', a single point in a file, and a
`location', a range composed of a pair of `position's (possibly
spanning several files).

   In this section `uint' is an abbreviation for `unsigned int': in
genuine code only the latter is used.

* Menu:

* C++ position::         One point in the source file
* C++ location::         Two points in the source file

\1f
File: bison.info,  Node: C++ position,  Next: C++ location,  Up: C++ Location Values

10.1.3.1 C++ `position'
.......................

 -- Constructor on position:  position (std::string* FILE = 0, uint
          LINE = 1, uint COL = 1)
     Create a `position' denoting a given point.  Note that `file' is
     not reclaimed when the `position' is destroyed: memory managed
     must be handled elsewhere.

 -- Method on position: void initialize (std::string* FILE = 0, uint
          LINE = 1, uint COL = 1)
     Reset the position to the given values.

 -- Instance Variable of position: std::string* file
     The name of the file.  It will always be handled as a pointer, the
     parser will never duplicate nor deallocate it.  As an experimental
     feature you may change it to `TYPE*' using `%define filename_type
     "TYPE"'.

 -- Instance Variable of position: uint line
     The line, starting at 1.

 -- Method on position: uint lines (int HEIGHT = 1)
     Advance by HEIGHT lines, resetting the column number.

 -- Instance Variable of position: uint column
     The column, starting at 1.

 -- Method on position: uint columns (int WIDTH = 1)
     Advance by WIDTH columns, without changing the line number.

 -- Method on position: position& operator+= (int WIDTH)
 -- Method on position: position operator+ (int WIDTH)
 -- Method on position: position& operator-= (int WIDTH)
 -- Method on position: position operator- (int WIDTH)
     Various forms of syntactic sugar for `columns'.

 -- Method on position: bool operator== (const position& THAT)
 -- Method on position: bool operator!= (const position& THAT)
     Whether `*this' and `that' denote equal/different positions.

 -- Function: std::ostream& operator<< (std::ostream& O, const
          position& P)
     Report P on O like this: `FILE:LINE.COLUMN', or `LINE.COLUMN' if
     FILE is null.

\1f
File: bison.info,  Node: C++ location,  Prev: C++ position,  Up: C++ Location Values

10.1.3.2 C++ `location'
.......................

 -- Constructor on location:  location (const position& BEGIN, const
          position& END)
     Create a `Location' from the endpoints of the range.

 -- Constructor on location:  location (const position& POS =
          position())
 -- Constructor on location:  location (std::string* FILE, uint LINE,
          uint COL)
     Create a `Location' denoting an empty range located at a given
     point.

 -- Method on location: void initialize (std::string* FILE = 0, uint
          LINE = 1, uint COL = 1)
     Reset the location to an empty range at the given values.

 -- Instance Variable of location: position begin
 -- Instance Variable of location: position end
     The first, inclusive, position of the range, and the first beyond.

 -- Method on location: uint columns (int WIDTH = 1)
 -- Method on location: uint lines (int HEIGHT = 1)
     Advance the `end' position.

 -- Method on location: location operator+ (const location& END)
 -- Method on location: location operator+ (int WIDTH)
 -- Method on location: location operator+= (int WIDTH)
     Various forms of syntactic sugar.

 -- Method on location: void step ()
     Move `begin' onto `end'.

 -- Method on location: bool operator== (const location& THAT)
 -- Method on location: bool operator!= (const location& THAT)
     Whether `*this' and `that' denote equal/different ranges of
     positions.

 -- Function: std::ostream& operator<< (std::ostream& O, const
          location& P)
     Report P on O, taking care of special cases such as: no `filename'
     defined, or equal filename/line or column.

\1f
File: bison.info,  Node: C++ Parser Interface,  Next: C++ Scanner Interface,  Prev: C++ Location Values,  Up: C++ Parsers

10.1.4 C++ Parser Interface
---------------------------

The output files `OUTPUT.hh' and `OUTPUT.cc' declare and define the
parser class in the namespace `yy'.  The class name defaults to
`parser', but may be changed using `%define parser_class_name "NAME"'.
The interface of this class is detailed below.  It can be extended
using the `%parse-param' feature: its semantics is slightly changed
since it describes an additional member of the parser class, and an
additional argument for its constructor.

 -- Type of parser: semantic_type
 -- Type of parser: location_type
     The types for semantics value and locations.

 -- Type of parser: token
     A structure that contains (only) the `yytokentype' enumeration,
     which defines the tokens.  To refer to the token `FOO', use
     `yy::parser::token::FOO'.  The scanner can use `typedef
     yy::parser::token token;' to "import" the token enumeration (*note
     Calc++ Scanner::).

 -- Method on parser:  parser (TYPE1 ARG1, ...)
     Build a new parser object.  There are no arguments by default,
     unless `%parse-param {TYPE1 ARG1}' was used.

 -- Method on parser: int parse ()
     Run the syntactic analysis, and return 0 on success, 1 otherwise.

 -- Method on parser: std::ostream& debug_stream ()
 -- Method on parser: void set_debug_stream (std::ostream& O)
     Get or set the stream used for tracing the parsing.  It defaults to
     `std::cerr'.

 -- Method on parser: debug_level_type debug_level ()
 -- Method on parser: void set_debug_level (debug_level L)
     Get or set the tracing level.  Currently its value is either 0, no
     trace, or nonzero, full tracing.

 -- Method on parser: void error (const location_type& L, const
          std::string& M)
     The definition for this member function must be supplied by the
     user: the parser uses it to report a parser error occurring at L,
     described by M.

\1f
File: bison.info,  Node: C++ Scanner Interface,  Next: A Complete C++ Example,  Prev: C++ Parser Interface,  Up: C++ Parsers

10.1.5 C++ Scanner Interface
----------------------------

The parser invokes the scanner by calling `yylex'.  Contrary to C
parsers, C++ parsers are always pure: there is no point in using the
`%define api.pure' directive.  Therefore the interface is as follows.

 -- Method on parser: int yylex (semantic_type* YYLVAL, location_type*
          YYLLOC, TYPE1 ARG1, ...)
     Return the next token.  Its type is the return value, its semantic
     value and location being YYLVAL and YYLLOC.  Invocations of
     `%lex-param {TYPE1 ARG1}' yield additional arguments.

\1f
File: bison.info,  Node: A Complete C++ Example,  Prev: C++ Scanner Interface,  Up: C++ Parsers

10.1.6 A Complete C++ Example
-----------------------------

This section demonstrates the use of a C++ parser with a simple but
complete example.  This example should be available on your system,
ready to compile, in the directory "../bison/examples/calc++".  It
focuses on the use of Bison, therefore the design of the various C++
classes is very naive: no accessors, no encapsulation of members etc.
We will use a Lex scanner, and more precisely, a Flex scanner, to
demonstrate the various interaction.  A hand written scanner is
actually easier to interface with.

* Menu:

* Calc++ --- C++ Calculator::   The specifications
* Calc++ Parsing Driver::       An active parsing context
* Calc++ Parser::               A parser class
* Calc++ Scanner::              A pure C++ Flex scanner
* Calc++ Top Level::            Conducting the band

\1f
File: bison.info,  Node: Calc++ --- C++ Calculator,  Next: Calc++ Parsing Driver,  Up: A Complete C++ Example

10.1.6.1 Calc++ -- C++ Calculator
.................................

Of course the grammar is dedicated to arithmetics, a single expression,
possibly preceded by variable assignments.  An environment containing
possibly predefined variables such as `one' and `two', is exchanged
with the parser.  An example of valid input follows.

     three := 3
     seven := one + two * three
     seven * seven

\1f
File: bison.info,  Node: Calc++ Parsing Driver,  Next: Calc++ Parser,  Prev: Calc++ --- C++ Calculator,  Up: A Complete C++ Example

10.1.6.2 Calc++ Parsing Driver
..............................

To support a pure interface with the parser (and the scanner) the
technique of the "parsing context" is convenient: a structure
containing all the data to exchange.  Since, in addition to simply
launch the parsing, there are several auxiliary tasks to execute (open
the file for parsing, instantiate the parser etc.), we recommend
transforming the simple parsing context structure into a fully blown
"parsing driver" class.

   The declaration of this driver class, `calc++-driver.hh', is as
follows.  The first part includes the CPP guard and imports the
required standard library components, and the declaration of the parser
class.

     #ifndef CALCXX_DRIVER_HH
     # define CALCXX_DRIVER_HH
     # include <string>
     # include <map>
     # include "calc++-parser.hh"

Then comes the declaration of the scanning function.  Flex expects the
signature of `yylex' to be defined in the macro `YY_DECL', and the C++
parser expects it to be declared.  We can factor both as follows.

     // Tell Flex the lexer's prototype ...
     # define YY_DECL                                        \
       yy::calcxx_parser::token_type                         \
       yylex (yy::calcxx_parser::semantic_type* yylval,      \
              yy::calcxx_parser::location_type* yylloc,      \
              calcxx_driver& driver)
     // ... and declare it for the parser's sake.
     YY_DECL;

The `calcxx_driver' class is then declared with its most obvious
members.

     // Conducting the whole scanning and parsing of Calc++.
     class calcxx_driver
     {
     public:
       calcxx_driver ();
       virtual ~calcxx_driver ();

       std::map<std::string, int> variables;

       int result;

To encapsulate the coordination with the Flex scanner, it is useful to
have two members function to open and close the scanning phase.

       // Handling the scanner.
       void scan_begin ();
       void scan_end ();
       bool trace_scanning;

Similarly for the parser itself.

       // Run the parser.  Return 0 on success.
       int parse (const std::string& f);
       std::string file;
       bool trace_parsing;

To demonstrate pure handling of parse errors, instead of simply dumping
them on the standard error output, we will pass them to the compiler
driver using the following two member functions.  Finally, we close the
class declaration and CPP guard.

       // Error handling.
       void error (const yy::location& l, const std::string& m);
       void error (const std::string& m);
     };
     #endif // ! CALCXX_DRIVER_HH

   The implementation of the driver is straightforward.  The `parse'
member function deserves some attention.  The `error' functions are
simple stubs, they should actually register the located error messages
and set error state.

     #include "calc++-driver.hh"
     #include "calc++-parser.hh"

     calcxx_driver::calcxx_driver ()
       : trace_scanning (false), trace_parsing (false)
     {
       variables["one"] = 1;
       variables["two"] = 2;
     }

     calcxx_driver::~calcxx_driver ()
     {
     }

     int
     calcxx_driver::parse (const std::string &f)
     {
       file = f;
       scan_begin ();
       yy::calcxx_parser parser (*this);
       parser.set_debug_level (trace_parsing);
       int res = parser.parse ();
       scan_end ();
       return res;
     }

     void
     calcxx_driver::error (const yy::location& l, const std::string& m)
     {
       std::cerr << l << ": " << m << std::endl;
     }

     void
     calcxx_driver::error (const std::string& m)
     {
       std::cerr << m << std::endl;
     }

\1f
File: bison.info,  Node: Calc++ Parser,  Next: Calc++ Scanner,  Prev: Calc++ Parsing Driver,  Up: A Complete C++ Example

10.1.6.3 Calc++ Parser
......................

The grammar file `calc++-parser.yy' starts by asking for the C++
deterministic parser skeleton, the creation of the parser header file,
and specifies the name of the parser class.  Because the C++ skeleton
changed several times, it is safer to require the version you designed
the grammar for.

     %skeleton "lalr1.cc" /* -*- C++ -*- */
     %require "2.6.1-dirty"
     %defines
     %define parser_class_name "calcxx_parser"

Then come the declarations/inclusions needed to define the `%union'.
Because the parser uses the parsing driver and reciprocally, both
cannot include the header of the other.  Because the driver's header
needs detailed knowledge about the parser class (in particular its
inner types), it is the parser's header which will simply use a forward
declaration of the driver.  *Note %code Summary::.

     %code requires {
     # include <string>
     class calcxx_driver;
     }

The driver is passed by reference to the parser and to the scanner.
This provides a simple but effective pure interface, not relying on
global variables.

     // The parsing context.
     %parse-param { calcxx_driver& driver }
     %lex-param   { calcxx_driver& driver }

Then we request the location tracking feature, and initialize the first
location's file name.  Afterward new locations are computed relatively
to the previous locations: the file name will be automatically
propagated.

     %locations
     %initial-action
     {
       // Initialize the initial location.
       @$.begin.filename = @$.end.filename = &driver.file;
     };

Use the two following directives to enable parser tracing and verbose
error messages.  However, verbose error messages can contain incorrect
information (*note LAC::).

     %debug
     %error-verbose

Semantic values cannot use "real" objects, but only pointers to them.

     // Symbols.
     %union
     {
       int          ival;
       std::string *sval;
     };

The code between `%code {' and `}' is output in the `*.cc' file; it
needs detailed knowledge about the driver.

     %code {
     # include "calc++-driver.hh"
     }

The token numbered as 0 corresponds to end of file; the following line
allows for nicer error messages referring to "end of file" instead of
"$end".  Similarly user friendly named are provided for each symbol.
Note that the tokens names are prefixed by `TOKEN_' to avoid name
clashes.

     %token        END      0 "end of file"
     %token        ASSIGN     ":="
     %token <sval> IDENTIFIER "identifier"
     %token <ival> NUMBER     "number"
     %type  <ival> exp

To enable memory deallocation during error recovery, use `%destructor'.

     %printer    { yyoutput << *$$; } "identifier"
     %destructor { delete $$; } "identifier"

     %printer    { yyoutput << $$; } <ival>

The grammar itself is straightforward.

     %%
     %start unit;
     unit: assignments exp  { driver.result = $2; };

     assignments:
       /* Nothing.  */        {}
     | assignments assignment {};

     assignment:
          "identifier" ":=" exp
            { driver.variables[*$1] = $3; delete $1; };

     %left '+' '-';
     %left '*' '/';
     exp: exp '+' exp   { $$ = $1 + $3; }
        | exp '-' exp   { $$ = $1 - $3; }
        | exp '*' exp   { $$ = $1 * $3; }
        | exp '/' exp   { $$ = $1 / $3; }
        | "identifier"  { $$ = driver.variables[*$1]; delete $1; }
        | "number"      { $$ = $1; };
     %%

Finally the `error' member function registers the errors to the driver.

     void
     yy::calcxx_parser::error (const yy::calcxx_parser::location_type& l,
                               const std::string& m)
     {
       driver.error (l, m);
     }

\1f
File: bison.info,  Node: Calc++ Scanner,  Next: Calc++ Top Level,  Prev: Calc++ Parser,  Up: A Complete C++ Example

10.1.6.4 Calc++ Scanner
.......................

The Flex scanner first includes the driver declaration, then the
parser's to get the set of defined tokens.

     %{ /* -*- C++ -*- */
     # include <cstdlib>
     # include <cerrno>
     # include <climits>
     # include <string>
     # include "calc++-driver.hh"
     # include "calc++-parser.hh"

     /* Work around an incompatibility in flex (at least versions
        2.5.31 through 2.5.33): it generates code that does
        not conform to C89.  See Debian bug 333231
        <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333231>.  */
     # undef yywrap
     # define yywrap() 1

     /* By default yylex returns int, we use token_type.
        Unfortunately yyterminate by default returns 0, which is
        not of token_type.  */
     #define yyterminate() return token::END
     %}

Because there is no `#include'-like feature we don't need `yywrap', we
don't need `unput' either, and we parse an actual file, this is not an
interactive session with the user.  Finally we enable the scanner
tracing features.

     %option noyywrap nounput batch debug

Abbreviations allow for more readable rules.

     id    [a-zA-Z][a-zA-Z_0-9]*
     int   [0-9]+
     blank [ \t]

The following paragraph suffices to track locations accurately.  Each
time `yylex' is invoked, the begin position is moved onto the end
position.  Then when a pattern is matched, the end position is advanced
of its width.  In case it matched ends of lines, the end cursor is
adjusted, and each time blanks are matched, the begin cursor is moved
onto the end cursor to effectively ignore the blanks preceding tokens.
Comments would be treated equally.

     %{
     # define YY_USER_ACTION  yylloc->columns (yyleng);
     %}
     %%
     %{
       yylloc->step ();
     %}
     {blank}+   yylloc->step ();
     [\n]+      yylloc->lines (yyleng); yylloc->step ();

The rules are simple, just note the use of the driver to report errors.
It is convenient to use a typedef to shorten
`yy::calcxx_parser::token::identifier' into `token::identifier' for
instance.

     %{
       typedef yy::calcxx_parser::token token;
     %}
                /* Convert ints to the actual type of tokens.  */
     [-+*/]     return yy::calcxx_parser::token_type (yytext[0]);
     ":="       return token::ASSIGN;
     {int}      {
       errno = 0;
       long n = strtol (yytext, NULL, 10);
       if (! (INT_MIN <= n && n <= INT_MAX && errno != ERANGE))
         driver.error (*yylloc, "integer is out of range");
       yylval->ival = n;
       return token::NUMBER;
     }
     {id}       yylval->sval = new std::string (yytext); return token::IDENTIFIER;
     .          driver.error (*yylloc, "invalid character");
     %%

Finally, because the scanner related driver's member function depend on
the scanner's data, it is simpler to implement them in this file.

     void
     calcxx_driver::scan_begin ()
     {
       yy_flex_debug = trace_scanning;
       if (file.empty () || file == "-")
         yyin = stdin;
       else if (!(yyin = fopen (file.c_str (), "r")))
         {
           error ("cannot open " + file + ": " + strerror(errno));
           exit (EXIT_FAILURE);
         }
     }

     void
     calcxx_driver::scan_end ()
     {
       fclose (yyin);
     }

\1f
File: bison.info,  Node: Calc++ Top Level,  Prev: Calc++ Scanner,  Up: A Complete C++ Example

10.1.6.5 Calc++ Top Level
.........................

The top level file, `calc++.cc', poses no problem.

     #include <iostream>
     #include "calc++-driver.hh"

     int
     main (int argc, char *argv[])
     {
       calcxx_driver driver;
       for (int i = 1; i < argc; ++i)
         if (argv[i] == std::string ("-p"))
           driver.trace_parsing = true;
         else if (argv[i] == std::string ("-s"))
           driver.trace_scanning = true;
         else if (!driver.parse (argv[i]))
           std::cout << driver.result << std::endl;
     }

\1f
File: bison.info,  Node: Java Parsers,  Prev: C++ Parsers,  Up: Other Languages

10.2 Java Parsers
=================

* Menu:

* Java Bison Interface::        Asking for Java parser generation
* Java Semantic Values::        %type and %token vs. Java
* Java Location Values::        The position and location classes
* Java Parser Interface::       Instantiating and running the parser
* Java Scanner Interface::      Specifying the scanner for the parser
* Java Action Features::        Special features for use in actions
* Java Differences::            Differences between C/C++ and Java Grammars
* Java Declarations Summary::   List of Bison declarations used with Java

\1f
File: bison.info,  Node: Java Bison Interface,  Next: Java Semantic Values,  Up: Java Parsers

10.2.1 Java Bison Interface
---------------------------

(The current Java interface is experimental and may evolve.  More user
feedback will help to stabilize it.)

   The Java parser skeletons are selected using the `%language "Java"'
directive or the `-L java'/`--language=java' option.

   When generating a Java parser, `bison BASENAME.y' will create a
single Java source file named `BASENAME.java' containing the parser
implementation.  Using a grammar file without a `.y' suffix is
currently broken.  The basename of the parser implementation file can
be changed by the `%file-prefix' directive or the `-p'/`--name-prefix'
option.  The entire parser implementation file name can be changed by
the `%output' directive or the `-o'/`--output' option.  The parser
implementation file contains a single class for the parser.

   You can create documentation for generated parsers using Javadoc.

   Contrary to C parsers, Java parsers do not use global variables; the
state of the parser is always local to an instance of the parser class.
Therefore, all Java parsers are "pure", and the `%pure-parser' and
`%define api.pure' directives does not do anything when used in Java.

   Push parsers are currently unsupported in Java and `%define
api.push-pull' have no effect.

   GLR parsers are currently unsupported in Java.  Do not use the
`glr-parser' directive.

   No header file can be generated for Java parsers.  Do not use the
`%defines' directive or the `-d'/`--defines' options.

   Currently, support for debugging and verbose errors are always
compiled in.  Thus the `%debug' and `%token-table' directives and the
`-t'/`--debug' and `-k'/`--token-table' options have no effect.  This
may change in the future to eliminate unused code in the generated
parser, so use `%debug' and `%verbose-error' explicitly if needed.
Also, in the future the `%token-table' directive might enable a public
interface to access the token names and codes.

\1f
File: bison.info,  Node: Java Semantic Values,  Next: Java Location Values,  Prev: Java Bison Interface,  Up: Java Parsers

10.2.2 Java Semantic Values
---------------------------

There is no `%union' directive in Java parsers.  Instead, the semantic
values' types (class names) should be specified in the `%type' or
`%token' directive:

     %type <Expression> expr assignment_expr term factor
     %type <Integer> number

   By default, the semantic stack is declared to have `Object' members,
which means that the class types you specify can be of any class.  To
improve the type safety of the parser, you can declare the common
superclass of all the semantic values using the `%define stype'
directive.  For example, after the following declaration:

     %define stype "ASTNode"

any `%type' or `%token' specifying a semantic type which is not a
subclass of ASTNode, will cause a compile-time error.

   Types used in the directives may be qualified with a package name.
Primitive data types are accepted for Java version 1.5 or later.  Note
that in this case the autoboxing feature of Java 1.5 will be used.
Generic types may not be used; this is due to a limitation in the
implementation of Bison, and may change in future releases.

   Java parsers do not support `%destructor', since the language adopts
garbage collection.  The parser will try to hold references to semantic
values for as little time as needed.

   Java parsers do not support `%printer', as `toString()' can be used
to print the semantic values.  This however may change (in a
backwards-compatible way) in future versions of Bison.

\1f
File: bison.info,  Node: Java Location Values,  Next: Java Parser Interface,  Prev: Java Semantic Values,  Up: Java Parsers

10.2.3 Java Location Values
---------------------------

When the directive `%locations' is used, the Java parser supports
location tracking, see *note Tracking Locations::.  An auxiliary
user-defined class defines a "position", a single point in a file;
Bison itself defines a class representing a "location", a range
composed of a pair of positions (possibly spanning several files).  The
location class is an inner class of the parser; the name is `Location'
by default, and may also be renamed using `%define location_type
"CLASS-NAME"'.

   The location class treats the position as a completely opaque value.
By default, the class name is `Position', but this can be changed with
`%define position_type "CLASS-NAME"'.  This class must be supplied by
the user.

 -- Instance Variable of Location: Position begin
 -- Instance Variable of Location: Position end
     The first, inclusive, position of the range, and the first beyond.

 -- Constructor on Location:  Location (Position LOC)
     Create a `Location' denoting an empty range located at a given
     point.

 -- Constructor on Location:  Location (Position BEGIN, Position END)
     Create a `Location' from the endpoints of the range.

 -- Method on Location: String toString ()
     Prints the range represented by the location.  For this to work
     properly, the position class should override the `equals' and
     `toString' methods appropriately.

\1f
File: bison.info,  Node: Java Parser Interface,  Next: Java Scanner Interface,  Prev: Java Location Values,  Up: Java Parsers

10.2.4 Java Parser Interface
----------------------------

The name of the generated parser class defaults to `YYParser'.  The
`YY' prefix may be changed using the `%name-prefix' directive or the
`-p'/`--name-prefix' option.  Alternatively, use `%define
parser_class_name "NAME"' to give a custom name to the class.  The
interface of this class is detailed below.

   By default, the parser class has package visibility.  A declaration
`%define public' will change to public visibility.  Remember that,
according to the Java language specification, the name of the `.java'
file should match the name of the class in this case.  Similarly, you
can use `abstract', `final' and `strictfp' with the `%define'
declaration to add other modifiers to the parser class.

   The Java package name of the parser class can be specified using the
`%define package' directive.  The superclass and the implemented
interfaces of the parser class can be specified with the `%define
extends' and `%define implements' directives.

   The parser class defines an inner class, `Location', that is used
for location tracking (see *note Java Location Values::), and a inner
interface, `Lexer' (see *note Java Scanner Interface::).  Other than
these inner class/interface, and the members described in the interface
below, all the other members and fields are preceded with a `yy' or
`YY' prefix to avoid clashes with user code.

   The parser class can be extended using the `%parse-param' directive.
Each occurrence of the directive will add a `protected final' field to
the parser class, and an argument to its constructor, which initialize
them automatically.

   Token names defined by `%token' and the predefined `EOF' token name
are added as constant fields to the parser class.

 -- Constructor on YYParser:  YYParser (LEX_PARAM, ..., PARSE_PARAM,
          ...)
     Build a new parser object with embedded `%code lexer'.  There are
     no parameters, unless `%parse-param's and/or `%lex-param's are
     used.

 -- Constructor on YYParser:  YYParser (Lexer LEXER, PARSE_PARAM, ...)
     Build a new parser object using the specified scanner.  There are
     no additional parameters unless `%parse-param's are used.

     If the scanner is defined by `%code lexer', this constructor is
     declared `protected' and is called automatically with a scanner
     created with the correct `%lex-param's.

 -- Method on YYParser: boolean parse ()
     Run the syntactic analysis, and return `true' on success, `false'
     otherwise.

 -- Method on YYParser: boolean recovering ()
     During the syntactic analysis, return `true' if recovering from a
     syntax error.  *Note Error Recovery::.

 -- Method on YYParser: java.io.PrintStream getDebugStream ()
 -- Method on YYParser: void setDebugStream (java.io.printStream O)
     Get or set the stream used for tracing the parsing.  It defaults to
     `System.err'.

 -- Method on YYParser: int getDebugLevel ()
 -- Method on YYParser: void setDebugLevel (int L)
     Get or set the tracing level.  Currently its value is either 0, no
     trace, or nonzero, full tracing.

\1f
File: bison.info,  Node: Java Scanner Interface,  Next: Java Action Features,  Prev: Java Parser Interface,  Up: Java Parsers

10.2.5 Java Scanner Interface
-----------------------------

There are two possible ways to interface a Bison-generated Java parser
with a scanner: the scanner may be defined by `%code lexer', or defined
elsewhere.  In either case, the scanner has to implement the `Lexer'
inner interface of the parser class.

   In the first case, the body of the scanner class is placed in `%code
lexer' blocks.  If you want to pass parameters from the parser
constructor to the scanner constructor, specify them with `%lex-param';
they are passed before `%parse-param's to the constructor.

   In the second case, the scanner has to implement the `Lexer'
interface, which is defined within the parser class (e.g.,
`YYParser.Lexer').  The constructor of the parser object will then
accept an object implementing the interface; `%lex-param' is not used
in this case.

   In both cases, the scanner has to implement the following methods.

 -- Method on Lexer: void yyerror (Location LOC, String MSG)
     This method is defined by the user to emit an error message.  The
     first parameter is omitted if location tracking is not active.
     Its type can be changed using `%define location_type "CLASS-NAME".'

 -- Method on Lexer: int yylex ()
     Return the next token.  Its type is the return value, its semantic
     value and location are saved and returned by the their methods in
     the interface.

     Use `%define lex_throws' to specify any uncaught exceptions.
     Default is `java.io.IOException'.

 -- Method on Lexer: Position getStartPos ()
 -- Method on Lexer: Position getEndPos ()
     Return respectively the first position of the last token that
     `yylex' returned, and the first position beyond it.  These methods
     are not needed unless location tracking is active.

     The return type can be changed using `%define position_type
     "CLASS-NAME".'

 -- Method on Lexer: Object getLVal ()
     Return the semantic value of the last token that yylex returned.

     The return type can be changed using `%define stype "CLASS-NAME".'

\1f
File: bison.info,  Node: Java Action Features,  Next: Java Differences,  Prev: Java Scanner Interface,  Up: Java Parsers

10.2.6 Special Features for Use in Java Actions
-----------------------------------------------

The following special constructs can be uses in Java actions.  Other
analogous C action features are currently unavailable for Java.

   Use `%define throws' to specify any uncaught exceptions from parser
actions, and initial actions specified by `%initial-action'.

 -- Variable: $N
     The semantic value for the Nth component of the current rule.
     This may not be assigned to.  *Note Java Semantic Values::.

 -- Variable: $<TYPEALT>N
     Like `$N' but specifies a alternative type TYPEALT.  *Note Java
     Semantic Values::.

 -- Variable: $$
     The semantic value for the grouping made by the current rule.  As a
     value, this is in the base type (`Object' or as specified by
     `%define stype') as in not cast to the declared subtype because
     casts are not allowed on the left-hand side of Java assignments.
     Use an explicit Java cast if the correct subtype is needed.  *Note
     Java Semantic Values::.

 -- Variable: $<TYPEALT>$
     Same as `$$' since Java always allow assigning to the base type.
     Perhaps we should use this and `$<>$' for the value and `$$' for
     setting the value but there is currently no easy way to distinguish
     these constructs.  *Note Java Semantic Values::.

 -- Variable: @N
     The location information of the Nth component of the current rule.
     This may not be assigned to.  *Note Java Location Values::.

 -- Variable: @$
     The location information of the grouping made by the current rule.
     *Note Java Location Values::.

 -- Statement: return YYABORT `;'
     Return immediately from the parser, indicating failure.  *Note
     Java Parser Interface::.

 -- Statement: return YYACCEPT `;'
     Return immediately from the parser, indicating success.  *Note
     Java Parser Interface::.

 -- Statement: return YYERROR `;'
     Start error recovery (without printing an error message).  *Note
     Error Recovery::.

 -- Function: boolean recovering ()
     Return whether error recovery is being done. In this state, the
     parser reads token until it reaches a known state, and then
     restarts normal operation.  *Note Error Recovery::.

 -- Function: protected void yyerror (String msg)
 -- Function: protected void yyerror (Position pos, String msg)
 -- Function: protected void yyerror (Location loc, String msg)
     Print an error message using the `yyerror' method of the scanner
     instance in use.

\1f
File: bison.info,  Node: Java Differences,  Next: Java Declarations Summary,  Prev: Java Action Features,  Up: Java Parsers

10.2.7 Differences between C/C++ and Java Grammars
--------------------------------------------------

The different structure of the Java language forces several differences
between C/C++ grammars, and grammars designed for Java parsers.  This
section summarizes these differences.

   * Java lacks a preprocessor, so the `YYERROR', `YYACCEPT', `YYABORT'
     symbols (*note Table of Symbols::) cannot obviously be macros.
     Instead, they should be preceded by `return' when they appear in
     an action.  The actual definition of these symbols is opaque to
     the Bison grammar, and it might change in the future.  The only
     meaningful operation that you can do, is to return them.  *Note
     Java Action Features::.

     Note that of these three symbols, only `YYACCEPT' and `YYABORT'
     will cause a return from the `yyparse' method(1).

   * Java lacks unions, so `%union' has no effect.  Instead, semantic
     values have a common base type: `Object' or as specified by
     `%define stype'.  Angle brackets on `%token', `type', `$N' and
     `$$' specify subtypes rather than fields of an union.  The type of
     `$$', even with angle brackets, is the base type since Java casts
     are not allow on the left-hand side of assignments.  Also, `$N'
     and `@N' are not allowed on the left-hand side of assignments.
     *Note Java Semantic Values::, and *note Java Action Features::.

   * The prologue declarations have a different meaning than in C/C++
     code.
    `%code imports'
          blocks are placed at the beginning of the Java source code.
          They may include copyright notices.  For a `package'
          declarations, it is suggested to use `%define package'
          instead.

    unqualified `%code'
          blocks are placed inside the parser class.

    `%code lexer'
          blocks, if specified, should include the implementation of the
          scanner.  If there is no such block, the scanner can be any
          class that implements the appropriate interface (*note Java
          Scanner Interface::).

     Other `%code' blocks are not supported in Java parsers.  In
     particular, `%{ ... %}' blocks should not be used and may give an
     error in future versions of Bison.

     The epilogue has the same meaning as in C/C++ code and it can be
     used to define other classes used by the parser _outside_ the
     parser class.

   ---------- Footnotes ----------

   (1) Java parsers include the actions in a separate method than
`yyparse' in order to have an intuitive syntax that corresponds to
these C macros.

\1f
File: bison.info,  Node: Java Declarations Summary,  Prev: Java Differences,  Up: Java Parsers

10.2.8 Java Declarations Summary
--------------------------------

This summary only include declarations specific to Java or have special
meaning when used in a Java parser.

 -- Directive: %language "Java"
     Generate a Java class for the parser.

 -- Directive: %lex-param {TYPE NAME}
     A parameter for the lexer class defined by `%code lexer' _only_,
     added as parameters to the lexer constructor and the parser
     constructor that _creates_ a lexer.  Default is none.  *Note Java
     Scanner Interface::.

 -- Directive: %name-prefix "PREFIX"
     The prefix of the parser class name `PREFIXParser' if `%define
     parser_class_name' is not used.  Default is `YY'.  *Note Java
     Bison Interface::.

 -- Directive: %parse-param {TYPE NAME}
     A parameter for the parser class added as parameters to
     constructor(s) and as fields initialized by the constructor(s).
     Default is none.  *Note Java Parser Interface::.

 -- Directive: %token <TYPE> TOKEN ...
     Declare tokens.  Note that the angle brackets enclose a Java
     _type_.  *Note Java Semantic Values::.

 -- Directive: %type <TYPE> NONTERMINAL ...
     Declare the type of nonterminals.  Note that the angle brackets
     enclose a Java _type_.  *Note Java Semantic Values::.

 -- Directive: %code { CODE ... }
     Code appended to the inside of the parser class.  *Note Java
     Differences::.

 -- Directive: %code imports { CODE ... }
     Code inserted just after the `package' declaration.  *Note Java
     Differences::.

 -- Directive: %code lexer { CODE ... }
     Code added to the body of a inner lexer class within the parser
     class.  *Note Java Scanner Interface::.

 -- Directive: %% CODE ...
     Code (after the second `%%') appended to the end of the file,
     _outside_ the parser class.  *Note Java Differences::.

 -- Directive: %{ CODE ... %}
     Not supported.  Use `%code import' instead.  *Note Java
     Differences::.

 -- Directive: %define abstract
     Whether the parser class is declared `abstract'.  Default is false.
     *Note Java Bison Interface::.

 -- Directive: %define extends "SUPERCLASS"
     The superclass of the parser class.  Default is none.  *Note Java
     Bison Interface::.

 -- Directive: %define final
     Whether the parser class is declared `final'.  Default is false.
     *Note Java Bison Interface::.

 -- Directive: %define implements "INTERFACES"
     The implemented interfaces of the parser class, a comma-separated
     list.  Default is none.  *Note Java Bison Interface::.

 -- Directive: %define lex_throws "EXCEPTIONS"
     The exceptions thrown by the `yylex' method of the lexer, a
     comma-separated list.  Default is `java.io.IOException'.  *Note
     Java Scanner Interface::.

 -- Directive: %define location_type "CLASS"
     The name of the class used for locations (a range between two
     positions).  This class is generated as an inner class of the
     parser class by `bison'.  Default is `Location'.  *Note Java
     Location Values::.

 -- Directive: %define package "PACKAGE"
     The package to put the parser class in.  Default is none.  *Note
     Java Bison Interface::.

 -- Directive: %define parser_class_name "NAME"
     The name of the parser class.  Default is `YYParser' or
     `NAME-PREFIXParser'.  *Note Java Bison Interface::.

 -- Directive: %define position_type "CLASS"
     The name of the class used for positions. This class must be
     supplied by the user.  Default is `Position'.  *Note Java Location
     Values::.

 -- Directive: %define public
     Whether the parser class is declared `public'.  Default is false.
     *Note Java Bison Interface::.

 -- Directive: %define stype "CLASS"
     The base type of semantic values.  Default is `Object'.  *Note
     Java Semantic Values::.

 -- Directive: %define strictfp
     Whether the parser class is declared `strictfp'.  Default is false.
     *Note Java Bison Interface::.

 -- Directive: %define throws "EXCEPTIONS"
     The exceptions thrown by user-supplied parser actions and
     `%initial-action', a comma-separated list.  Default is none.
     *Note Java Parser Interface::.

\1f
File: bison.info,  Node: FAQ,  Next: Table of Symbols,  Prev: Other Languages,  Up: Top

11 Frequently Asked Questions
*****************************

Several questions about Bison come up occasionally.  Here some of them
are addressed.

* Menu:

* Memory Exhausted::            Breaking the Stack Limits
* How Can I Reset the Parser::  `yyparse' Keeps some State
* Strings are Destroyed::       `yylval' Loses Track of Strings
* Implementing Gotos/Loops::    Control Flow in the Calculator
* Multiple start-symbols::      Factoring closely related grammars
* Secure?  Conform?::           Is Bison POSIX safe?
* I can't build Bison::         Troubleshooting
* Where can I find help?::      Troubleshouting
* Bug Reports::                 Troublereporting
* More Languages::              Parsers in C++, Java, and so on
* Beta Testing::                Experimenting development versions
* Mailing Lists::               Meeting other Bison users

\1f
File: bison.info,  Node: Memory Exhausted,  Next: How Can I Reset the Parser,  Up: FAQ

11.1 Memory Exhausted
=====================

     My parser returns with error with a `memory exhausted' message.
     What can I do?

   This question is already addressed elsewhere, see *note Recursive
Rules: Recursion.

\1f
File: bison.info,  Node: How Can I Reset the Parser,  Next: Strings are Destroyed,  Prev: Memory Exhausted,  Up: FAQ

11.2 How Can I Reset the Parser
===============================

The following phenomenon has several symptoms, resulting in the
following typical questions:

     I invoke `yyparse' several times, and on correct input it works
     properly; but when a parse error is found, all the other calls fail
     too.  How can I reset the error flag of `yyparse'?

or

     My parser includes support for an `#include'-like feature, in
     which case I run `yyparse' from `yyparse'.  This fails although I
     did specify `%define api.pure'.

   These problems typically come not from Bison itself, but from
Lex-generated scanners.  Because these scanners use large buffers for
speed, they might not notice a change of input file.  As a
demonstration, consider the following source file, `first-line.l':

     %{
     #include <stdio.h>
     #include <stdlib.h>
     %}
     %%
     .*\n    ECHO; return 1;
     %%
     int
     yyparse (char const *file)
     {
       yyin = fopen (file, "r");
       if (!yyin)
         {
           perror ("fopen");
           exit (EXIT_FAILURE);
         }
       /* One token only.  */
       yylex ();
       if (fclose (yyin) != 0)
         {
           perror ("fclose");
           exit (EXIT_FAILURE);
         }
       return 0;
     }

     int
     main (void)
     {
       yyparse ("input");
       yyparse ("input");
       return 0;
     }

If the file `input' contains

     input:1: Hello,
     input:2: World!

then instead of getting the first line twice, you get:

     $ flex -ofirst-line.c first-line.l
     $ gcc  -ofirst-line   first-line.c -ll
     $ ./first-line
     input:1: Hello,
     input:2: World!

   Therefore, whenever you change `yyin', you must tell the
Lex-generated scanner to discard its current buffer and switch to the
new one.  This depends upon your implementation of Lex; see its
documentation for more.  For Flex, it suffices to call
`YY_FLUSH_BUFFER' after each change to `yyin'.  If your Flex-generated
scanner needs to read from several input streams to handle features
like include files, you might consider using Flex functions like
`yy_switch_to_buffer' that manipulate multiple input buffers.

   If your Flex-generated scanner uses start conditions (*note Start
conditions: (flex)Start conditions.), you might also want to reset the
scanner's state, i.e., go back to the initial start condition, through
a call to `BEGIN (0)'.

\1f
File: bison.info,  Node: Strings are Destroyed,  Next: Implementing Gotos/Loops,  Prev: How Can I Reset the Parser,  Up: FAQ

11.3 Strings are Destroyed
==========================

     My parser seems to destroy old strings, or maybe it loses track of
     them.  Instead of reporting `"foo", "bar"', it reports `"bar",
     "bar"', or even `"foo\nbar", "bar"'.

   This error is probably the single most frequent "bug report" sent to
Bison lists, but is only concerned with a misunderstanding of the role
of the scanner.  Consider the following Lex code:

     %{
     #include <stdio.h>
     char *yylval = NULL;
     %}
     %%
     .*    yylval = yytext; return 1;
     \n    /* IGNORE */
     %%
     int
     main ()
     {
       /* Similar to using $1, $2 in a Bison action.  */
       char *fst = (yylex (), yylval);
       char *snd = (yylex (), yylval);
       printf ("\"%s\", \"%s\"\n", fst, snd);
       return 0;
     }

   If you compile and run this code, you get:

     $ flex -osplit-lines.c split-lines.l
     $ gcc  -osplit-lines   split-lines.c -ll
     $ printf 'one\ntwo\n' | ./split-lines
     "one
     two", "two"

this is because `yytext' is a buffer provided for _reading_ in the
action, but if you want to keep it, you have to duplicate it (e.g.,
using `strdup').  Note that the output may depend on how your
implementation of Lex handles `yytext'.  For instance, when given the
Lex compatibility option `-l' (which triggers the option `%array') Flex
generates a different behavior:

     $ flex -l -osplit-lines.c split-lines.l
     $ gcc     -osplit-lines   split-lines.c -ll
     $ printf 'one\ntwo\n' | ./split-lines
     "two", "two"

\1f
File: bison.info,  Node: Implementing Gotos/Loops,  Next: Multiple start-symbols,  Prev: Strings are Destroyed,  Up: FAQ

11.4 Implementing Gotos/Loops
=============================

     My simple calculator supports variables, assignments, and
     functions, but how can I implement gotos, or loops?

   Although very pedagogical, the examples included in the document blur
the distinction to make between the parser--whose job is to recover the
structure of a text and to transmit it to subsequent modules of the
program--and the processing (such as the execution) of this structure.
This works well with so called straight line programs, i.e., precisely
those that have a straightforward execution model: execute simple
instructions one after the others.

   If you want a richer model, you will probably need to use the parser
to construct a tree that does represent the structure it has recovered;
this tree is usually called the "abstract syntax tree", or "AST" for
short.  Then, walking through this tree, traversing it in various ways,
will enable treatments such as its execution or its translation, which
will result in an interpreter or a compiler.

   This topic is way beyond the scope of this manual, and the reader is
invited to consult the dedicated literature.

\1f
File: bison.info,  Node: Multiple start-symbols,  Next: Secure? Conform?,  Prev: Implementing Gotos/Loops,  Up: FAQ

11.5 Multiple start-symbols
===========================

     I have several closely related grammars, and I would like to share
     their implementations.  In fact, I could use a single grammar but
     with multiple entry points.

   Bison does not support multiple start-symbols, but there is a very
simple means to simulate them.  If `foo' and `bar' are the two pseudo
start-symbols, then introduce two new tokens, say `START_FOO' and
`START_BAR', and use them as switches from the real start-symbol:

     %token START_FOO START_BAR;
     %start start;
     start:
       START_FOO foo
     | START_BAR bar;

   These tokens prevents the introduction of new conflicts.  As far as
the parser goes, that is all that is needed.

   Now the difficult part is ensuring that the scanner will send these
tokens first.  If your scanner is hand-written, that should be
straightforward.  If your scanner is generated by Lex, them there is
simple means to do it: recall that anything between `%{ ... %}' after
the first `%%' is copied verbatim in the top of the generated `yylex'
function.  Make sure a variable `start_token' is available in the
scanner (e.g., a global variable or using `%lex-param' etc.), and use
the following:

       /* Prologue.  */
     %%
     %{
       if (start_token)
         {
           int t = start_token;
           start_token = 0;
           return t;
         }
     %}
       /* The rules.  */

\1f
File: bison.info,  Node: Secure? Conform?,  Next: I can't build Bison,  Prev: Multiple start-symbols,  Up: FAQ

11.6 Secure?  Conform?
======================

     Is Bison secure?  Does it conform to POSIX?

   If you're looking for a guarantee or certification, we don't provide
it.  However, Bison is intended to be a reliable program that conforms
to the POSIX specification for Yacc.  If you run into problems, please
send us a bug report.

\1f
File: bison.info,  Node: I can't build Bison,  Next: Where can I find help?,  Prev: Secure? Conform?,  Up: FAQ

11.7 I can't build Bison
========================

     I can't build Bison because `make' complains that `msgfmt' is not
     found.  What should I do?

   Like most GNU packages with internationalization support, that
feature is turned on by default.  If you have problems building in the
`po' subdirectory, it indicates that your system's internationalization
support is lacking.  You can re-configure Bison with `--disable-nls' to
turn off this support, or you can install GNU gettext from
`ftp://ftp.gnu.org/gnu/gettext/' and re-configure Bison.  See the file
`ABOUT-NLS' for more information.

\1f
File: bison.info,  Node: Where can I find help?,  Next: Bug Reports,  Prev: I can't build Bison,  Up: FAQ

11.8 Where can I find help?
===========================

     I'm having trouble using Bison.  Where can I find help?

   First, read this fine manual.  Beyond that, you can send mail to
<help-bison@gnu.org>.  This mailing list is intended to be populated
with people who are willing to answer questions about using and
installing Bison.  Please keep in mind that (most of) the people on the
list have aspects of their lives which are not related to Bison (!), so
you may not receive an answer to your question right away.  This can be
frustrating, but please try not to honk them off; remember that any
help they provide is purely voluntary and out of the kindness of their
hearts.

\1f
File: bison.info,  Node: Bug Reports,  Next: More Languages,  Prev: Where can I find help?,  Up: FAQ

11.9 Bug Reports
================

     I found a bug.  What should I include in the bug report?

   Before you send a bug report, make sure you are using the latest
version.  Check `ftp://ftp.gnu.org/pub/gnu/bison/' or one of its
mirrors.  Be sure to include the version number in your bug report.  If
the bug is present in the latest version but not in a previous version,
try to determine the most recent version which did not contain the bug.

   If the bug is parser-related, you should include the smallest grammar
you can which demonstrates the bug.  The grammar file should also be
complete (i.e., I should be able to run it through Bison without having
to edit or add anything).  The smaller and simpler the grammar, the
easier it will be to fix the bug.

   Include information about your compilation environment, including
your operating system's name and version and your compiler's name and
version.  If you have trouble compiling, you should also include a
transcript of the build session, starting with the invocation of
`configure'.  Depending on the nature of the bug, you may be asked to
send additional files as well (such as `config.h' or `config.cache').

   Patches are most welcome, but not required.  That is, do not
hesitate to send a bug report just because you cannot provide a fix.

   Send bug reports to <bug-bison@gnu.org>.

\1f
File: bison.info,  Node: More Languages,  Next: Beta Testing,  Prev: Bug Reports,  Up: FAQ

11.10 More Languages
====================

     Will Bison ever have C++ and Java support?  How about INSERT YOUR
     FAVORITE LANGUAGE HERE?

   C++ and Java support is there now, and is documented.  We'd love to
add other languages; contributions are welcome.

\1f
File: bison.info,  Node: Beta Testing,  Next: Mailing Lists,  Prev: More Languages,  Up: FAQ

11.11 Beta Testing
==================

     What is involved in being a beta tester?

   It's not terribly involved.  Basically, you would download a test
release, compile it, and use it to build and run a parser or two.  After
that, you would submit either a bug report or a message saying that
everything is okay.  It is important to report successes as well as
failures because test releases eventually become mainstream releases,
but only if they are adequately tested.  If no one tests, development is
essentially halted.

   Beta testers are particularly needed for operating systems to which
the developers do not have easy access.  They currently have easy
access to recent GNU/Linux and Solaris versions.  Reports about other
operating systems are especially welcome.

\1f
File: bison.info,  Node: Mailing Lists,  Prev: Beta Testing,  Up: FAQ

11.12 Mailing Lists
===================

     How do I join the help-bison and bug-bison mailing lists?

   See `http://lists.gnu.org/'.

\1f
File: bison.info,  Node: Table of Symbols,  Next: Glossary,  Prev: FAQ,  Up: Top

Annexe A Bison Symbols
**********************

 -- Variable: @$
     In an action, the location of the left-hand side of the rule.
     *Note Tracking Locations::.

 -- Variable: @N
     In an action, the location of the N-th symbol of the right-hand
     side of the rule.  *Note Tracking Locations::.

 -- Variable: @NAME
     In an action, the location of a symbol addressed by name.  *Note
     Tracking Locations::.

 -- Variable: @[NAME]
     In an action, the location of a symbol addressed by name.  *Note
     Tracking Locations::.

 -- Variable: $$
     In an action, the semantic value of the left-hand side of the rule.
     *Note Actions::.

 -- Variable: $N
     In an action, the semantic value of the N-th symbol of the
     right-hand side of the rule.  *Note Actions::.

 -- Variable: $NAME
     In an action, the semantic value of a symbol addressed by name.
     *Note Actions::.

 -- Variable: $[NAME]
     In an action, the semantic value of a symbol addressed by name.
     *Note Actions::.

 -- Delimiter: %%
     Delimiter used to separate the grammar rule section from the Bison
     declarations section or the epilogue.  *Note The Overall Layout of
     a Bison Grammar: Grammar Layout.

 -- Delimiter: %{CODE%}
     All code listed between `%{' and `%}' is copied verbatim to the
     parser implementation file.  Such code forms the prologue of the
     grammar file.  *Note Outline of a Bison Grammar: Grammar Outline.

 -- Construct: /*...*/
     Comment delimiters, as in C.

 -- Delimiter: :
     Separates a rule's result from its components.  *Note Syntax of
     Grammar Rules: Rules.

 -- Delimiter: ;
     Terminates a rule.  *Note Syntax of Grammar Rules: Rules.

 -- Delimiter: |
     Separates alternate rules for the same result nonterminal.  *Note
     Syntax of Grammar Rules: Rules.

 -- Directive: <*>
     Used to define a default tagged `%destructor' or default tagged
     `%printer'.

     This feature is experimental.  More user feedback will help to
     determine whether it should become a permanent feature.

     *Note Freeing Discarded Symbols: Destructor Decl.

 -- Directive: <>
     Used to define a default tagless `%destructor' or default tagless
     `%printer'.

     This feature is experimental.  More user feedback will help to
     determine whether it should become a permanent feature.

     *Note Freeing Discarded Symbols: Destructor Decl.

 -- Symbol: $accept
     The predefined nonterminal whose only rule is `$accept: START
     $end', where START is the start symbol.  *Note The Start-Symbol:
     Start Decl.  It cannot be used in the grammar.

 -- Directive: %code {CODE}
 -- Directive: %code QUALIFIER {CODE}
     Insert CODE verbatim into the output parser source at the default
     location or at the location specified by QUALIFIER.  *Note %code
     Summary::.

 -- Directive: %debug
     Equip the parser for debugging.  *Note Decl Summary::.

 -- Directive: %define VARIABLE
 -- Directive: %define VARIABLE VALUE
 -- Directive: %define VARIABLE "VALUE"
     Define a variable to adjust Bison's behavior.  *Note %define
     Summary::.

 -- Directive: %defines
     Bison declaration to create a parser header file, which is usually
     meant for the scanner.  *Note Decl Summary::.

 -- Directive: %defines DEFINES-FILE
     Same as above, but save in the file DEFINES-FILE.  *Note Decl
     Summary::.

 -- Directive: %destructor
     Specify how the parser should reclaim the memory associated to
     discarded symbols.  *Note Freeing Discarded Symbols: Destructor
     Decl.

 -- Directive: %dprec
     Bison declaration to assign a precedence to a rule that is used at
     parse time to resolve reduce/reduce conflicts.  *Note Writing GLR
     Parsers: GLR Parsers.

 -- Symbol: $end
     The predefined token marking the end of the token stream.  It
     cannot be used in the grammar.

 -- Symbol: error
     A token name reserved for error recovery.  This token may be used
     in grammar rules so as to allow the Bison parser to recognize an
     error in the grammar without halting the process.  In effect, a
     sentence containing an error may be recognized as valid.  On a
     syntax error, the token `error' becomes the current lookahead
     token.  Actions corresponding to `error' are then executed, and
     the lookahead token is reset to the token that originally caused
     the violation.  *Note Error Recovery::.

 -- Directive: %error-verbose
     Bison declaration to request verbose, specific error message
     strings when `yyerror' is called.  *Note Error Reporting::.

 -- Directive: %file-prefix "PREFIX"
     Bison declaration to set the prefix of the output files.  *Note
     Decl Summary::.

 -- Directive: %glr-parser
     Bison declaration to produce a GLR parser.  *Note Writing GLR
     Parsers: GLR Parsers.

 -- Directive: %initial-action
     Run user code before parsing.  *Note Performing Actions before
     Parsing: Initial Action Decl.

 -- Directive: %language
     Specify the programming language for the generated parser.  *Note
     Decl Summary::.

 -- Directive: %left
     Bison declaration to assign left associativity to token(s).  *Note
     Operator Precedence: Precedence Decl.

 -- Directive: %lex-param {ARGUMENT-DECLARATION}
     Bison declaration to specifying an additional parameter that
     `yylex' should accept.  *Note Calling Conventions for Pure
     Parsers: Pure Calling.

 -- Directive: %merge
     Bison declaration to assign a merging function to a rule.  If
     there is a reduce/reduce conflict with a rule having the same
     merging function, the function is applied to the two semantic
     values to get a single result.  *Note Writing GLR Parsers: GLR
     Parsers.

 -- Directive: %name-prefix "PREFIX"
     Obsoleted by the `%define' variable `api.prefix' (*note Multiple
     Parsers in the Same Program: Multiple Parsers.).

     Rename the external symbols (variables and functions) used in the
     parser so that they start with PREFIX instead of `yy'.  Contrary to
     `api.prefix', do no rename types and macros.

     The precise list of symbols renamed in C parsers is `yyparse',
     `yylex', `yyerror', `yynerrs', `yylval', `yychar', `yydebug', and
     (if locations are used) `yylloc'.  If you use a push parser,
     `yypush_parse', `yypull_parse', `yypstate', `yypstate_new' and
     `yypstate_delete' will also be renamed.  For example, if you use
     `%name-prefix "c_"', the names become `c_parse', `c_lex', and so
     on.  For C++ parsers, see the `%define namespace' documentation in
     this section.

 -- Directive: %no-lines
     Bison declaration to avoid generating `#line' directives in the
     parser implementation file.  *Note Decl Summary::.

 -- Directive: %nonassoc
     Bison declaration to assign nonassociativity to token(s).  *Note
     Operator Precedence: Precedence Decl.

 -- Directive: %output "FILE"
     Bison declaration to set the name of the parser implementation
     file.  *Note Decl Summary::.

 -- Directive: %parse-param {ARGUMENT-DECLARATION}
     Bison declaration to specifying an additional parameter that
     `yyparse' should accept.  *Note The Parser Function `yyparse':
     Parser Function.

 -- Directive: %prec
     Bison declaration to assign a precedence to a specific rule.
     *Note Context-Dependent Precedence: Contextual Precedence.

 -- Directive: %pure-parser
     Deprecated version of `%define api.pure' (*note api.pure: %define
     Summary.), for which Bison is more careful to warn about
     unreasonable usage.

 -- Directive: %require "VERSION"
     Require version VERSION or higher of Bison.  *Note Require a
     Version of Bison: Require Decl.

 -- Directive: %right
     Bison declaration to assign right associativity to token(s).
     *Note Operator Precedence: Precedence Decl.

 -- Directive: %skeleton
     Specify the skeleton to use; usually for development.  *Note Decl
     Summary::.

 -- Directive: %start
     Bison declaration to specify the start symbol.  *Note The
     Start-Symbol: Start Decl.

 -- Directive: %token
     Bison declaration to declare token(s) without specifying
     precedence.  *Note Token Type Names: Token Decl.

 -- Directive: %token-table
     Bison declaration to include a token name table in the parser
     implementation file.  *Note Decl Summary::.

 -- Directive: %type
     Bison declaration to declare nonterminals.  *Note Nonterminal
     Symbols: Type Decl.

 -- Symbol: $undefined
     The predefined token onto which all undefined values returned by
     `yylex' are mapped.  It cannot be used in the grammar, rather, use
     `error'.

 -- Directive: %union
     Bison declaration to specify several possible data types for
     semantic values.  *Note The Collection of Value Types: Union Decl.

 -- Macro: YYABORT
     Macro to pretend that an unrecoverable syntax error has occurred,
     by making `yyparse' return 1 immediately.  The error reporting
     function `yyerror' is not called.  *Note The Parser Function
     `yyparse': Parser Function.

     For Java parsers, this functionality is invoked using `return
     YYABORT;' instead.

 -- Macro: YYACCEPT
     Macro to pretend that a complete utterance of the language has been
     read, by making `yyparse' return 0 immediately.  *Note The Parser
     Function `yyparse': Parser Function.

     For Java parsers, this functionality is invoked using `return
     YYACCEPT;' instead.

 -- Macro: YYBACKUP
     Macro to discard a value from the parser stack and fake a lookahead
     token.  *Note Special Features for Use in Actions: Action Features.

 -- Variable: yychar
     External integer variable that contains the integer value of the
     lookahead token.  (In a pure parser, it is a local variable within
     `yyparse'.)  Error-recovery rule actions may examine this variable.
     *Note Special Features for Use in Actions: Action Features.

 -- Variable: yyclearin
     Macro used in error-recovery rule actions.  It clears the previous
     lookahead token.  *Note Error Recovery::.

 -- Macro: YYDEBUG
     Macro to define to equip the parser with tracing code.  *Note
     Tracing Your Parser: Tracing.

 -- Variable: yydebug
     External integer variable set to zero by default.  If `yydebug' is
     given a nonzero value, the parser will output information on input
     symbols and parser action.  *Note Tracing Your Parser: Tracing.

 -- Macro: yyerrok
     Macro to cause parser to recover immediately to its normal mode
     after a syntax error.  *Note Error Recovery::.

 -- Macro: YYERROR
     Cause an immediate syntax error.  This statement initiates error
     recovery just as if the parser itself had detected an error;
     however, it does not call `yyerror', and does not print any
     message.  If you want to print an error message, call `yyerror'
     explicitly before the `YYERROR;' statement.  *Note Error
     Recovery::.

     For Java parsers, this functionality is invoked using `return
     YYERROR;' instead.

 -- Function: yyerror
     User-supplied function to be called by `yyparse' on error.  *Note
     The Error Reporting Function `yyerror': Error Reporting.

 -- Macro: YYERROR_VERBOSE
     An obsolete macro that you define with `#define' in the prologue
     to request verbose, specific error message strings when `yyerror'
     is called.  It doesn't matter what definition you use for
     `YYERROR_VERBOSE', just whether you define it.  Supported by the C
     skeletons only; using `%error-verbose' is preferred.  *Note Error
     Reporting::.

 -- Macro: YYFPRINTF
     Macro used to output run-time traces.  *Note Enabling Traces::.

 -- Macro: YYINITDEPTH
     Macro for specifying the initial size of the parser stack.  *Note
     Memory Management::.

 -- Function: yylex
     User-supplied lexical analyzer function, called with no arguments
     to get the next token.  *Note The Lexical Analyzer Function
     `yylex': Lexical.

 -- Macro: YYLEX_PARAM
     An obsolete macro for specifying an extra argument (or list of
     extra arguments) for `yyparse' to pass to `yylex'.  The use of this
     macro is deprecated, and is supported only for Yacc like parsers.
     *Note Calling Conventions for Pure Parsers: Pure Calling.

 -- Variable: yylloc
     External variable in which `yylex' should place the line and column
     numbers associated with a token.  (In a pure parser, it is a local
     variable within `yyparse', and its address is passed to `yylex'.)
     You can ignore this variable if you don't use the `@' feature in
     the grammar actions.  *Note Textual Locations of Tokens: Token
     Locations.  In semantic actions, it stores the location of the
     lookahead token.  *Note Actions and Locations: Actions and
     Locations.

 -- Type: YYLTYPE
     Data type of `yylloc'; by default, a structure with four members.
     *Note Data Types of Locations: Location Type.

 -- Variable: yylval
     External variable in which `yylex' should place the semantic value
     associated with a token.  (In a pure parser, it is a local
     variable within `yyparse', and its address is passed to `yylex'.)
     *Note Semantic Values of Tokens: Token Values.  In semantic
     actions, it stores the semantic value of the lookahead token.
     *Note Actions: Actions.

 -- Macro: YYMAXDEPTH
     Macro for specifying the maximum size of the parser stack.  *Note
     Memory Management::.

 -- Variable: yynerrs
     Global variable which Bison increments each time it reports a
     syntax error.  (In a pure parser, it is a local variable within
     `yyparse'. In a pure push parser, it is a member of yypstate.)
     *Note The Error Reporting Function `yyerror': Error Reporting.

 -- Function: yyparse
     The parser function produced by Bison; call this function to start
     parsing.  *Note The Parser Function `yyparse': Parser Function.

 -- Macro: YYPRINT
     Macro used to output token semantic values.  For `yacc.c' only.
     Obsoleted by `%printer'.  *Note The `YYPRINT' Macro: The YYPRINT
     Macro.

 -- Function: yypstate_delete
     The function to delete a parser instance, produced by Bison in
     push mode; call this function to delete the memory associated with
     a parser.  *Note The Parser Delete Function `yypstate_delete':
     Parser Delete Function.  (The current push parsing interface is
     experimental and may evolve.  More user feedback will help to
     stabilize it.)

 -- Function: yypstate_new
     The function to create a parser instance, produced by Bison in
     push mode; call this function to create a new parser.  *Note The
     Parser Create Function `yypstate_new': Parser Create Function.
     (The current push parsing interface is experimental and may evolve.
     More user feedback will help to stabilize it.)

 -- Function: yypull_parse
     The parser function produced by Bison in push mode; call this
     function to parse the rest of the input stream.  *Note The Pull
     Parser Function `yypull_parse': Pull Parser Function.  (The
     current push parsing interface is experimental and may evolve.
     More user feedback will help to stabilize it.)

 -- Function: yypush_parse
     The parser function produced by Bison in push mode; call this
     function to parse a single token.  *Note The Push Parser Function
     `yypush_parse': Push Parser Function.  (The current push parsing
     interface is experimental and may evolve.  More user feedback will
     help to stabilize it.)

 -- Macro: YYPARSE_PARAM
     An obsolete macro for specifying the name of a parameter that
     `yyparse' should accept.  The use of this macro is deprecated, and
     is supported only for Yacc like parsers.  *Note Calling
     Conventions for Pure Parsers: Pure Calling.

 -- Macro: YYRECOVERING
     The expression `YYRECOVERING ()' yields 1 when the parser is
     recovering from a syntax error, and 0 otherwise.  *Note Special
     Features for Use in Actions: Action Features.

 -- Macro: YYSTACK_USE_ALLOCA
     Macro used to control the use of `alloca' when the deterministic
     parser in C needs to extend its stacks.  If defined to 0, the
     parser will use `malloc' to extend its stacks.  If defined to 1,
     the parser will use `alloca'.  Values other than 0 and 1 are
     reserved for future Bison extensions.  If not defined,
     `YYSTACK_USE_ALLOCA' defaults to 0.

     In the all-too-common case where your code may run on a host with a
     limited stack and with unreliable stack-overflow checking, you
     should set `YYMAXDEPTH' to a value that cannot possibly result in
     unchecked stack overflow on any of your target hosts when `alloca'
     is called.  You can inspect the code that Bison generates in order
     to determine the proper numeric values.  This will require some
     expertise in low-level implementation details.

 -- Type: YYSTYPE
     Data type of semantic values; `int' by default.  *Note Data Types
     of Semantic Values: Value Type.

\1f
File: bison.info,  Node: Glossary,  Next: Copying This Manual,  Prev: Table of Symbols,  Up: Top

Annexe B Glossary
*****************

Accepting state
     A state whose only action is the accept action.  The accepting
     state is thus a consistent state.  *Note Understanding::.

Backus-Naur Form (BNF; also called "Backus Normal Form")
     Formal method of specifying context-free grammars originally
     proposed by John Backus, and slightly improved by Peter Naur in
     his 1960-01-02 committee document contributing to what became the
     Algol 60 report.  *Note Languages and Context-Free Grammars:
     Language and Grammar.

Consistent state
     A state containing only one possible action.  *Note Default
     Reductions::.

Context-free grammars
     Grammars specified as rules that can be applied regardless of
     context.  Thus, if there is a rule which says that an integer can
     be used as an expression, integers are allowed _anywhere_ an
     expression is permitted.  *Note Languages and Context-Free
     Grammars: Language and Grammar.

Default reduction
     The reduction that a parser should perform if the current parser
     state contains no other action for the lookahead token.  In
     permitted parser states, Bison declares the reduction with the
     largest lookahead set to be the default reduction and removes that
     lookahead set.  *Note Default Reductions::.

Defaulted state
     A consistent state with a default reduction.  *Note Default
     Reductions::.

Dynamic allocation
     Allocation of memory that occurs during execution, rather than at
     compile time or on entry to a function.

Empty string
     Analogous to the empty set in set theory, the empty string is a
     character string of length zero.

Finite-state stack machine
     A "machine" that has discrete states in which it is said to exist
     at each instant in time.  As input to the machine is processed, the
     machine moves from state to state as specified by the logic of the
     machine.  In the case of the parser, the input is the language
     being parsed, and the states correspond to various stages in the
     grammar rules.  *Note The Bison Parser Algorithm: Algorithm.

Generalized LR (GLR)
     A parsing algorithm that can handle all context-free grammars,
     including those that are not LR(1).  It resolves situations that
     Bison's deterministic parsing algorithm cannot by effectively
     splitting off multiple parsers, trying all possible parsers, and
     discarding those that fail in the light of additional right
     context.  *Note Generalized LR Parsing: Generalized LR Parsing.

Grouping
     A language construct that is (in general) grammatically divisible;
     for example, `expression' or `declaration' in C.  *Note Languages
     and Context-Free Grammars: Language and Grammar.

IELR(1) (Inadequacy Elimination LR(1))
     A minimal LR(1) parser table construction algorithm.  That is,
     given any context-free grammar, IELR(1) generates parser tables
     with the full language-recognition power of canonical LR(1) but
     with nearly the same number of parser states as LALR(1).  This
     reduction in parser states is often an order of magnitude.  More
     importantly, because canonical LR(1)'s extra parser states may
     contain duplicate conflicts in the case of non-LR(1) grammars, the
     number of conflicts for IELR(1) is often an order of magnitude
     less as well.  This can significantly reduce the complexity of
     developing a grammar.  *Note LR Table Construction::.

Infix operator
     An arithmetic operator that is placed between the operands on
     which it performs some operation.

Input stream
     A continuous flow of data between devices or programs.

LAC (Lookahead Correction)
     A parsing mechanism that fixes the problem of delayed syntax error
     detection, which is caused by LR state merging, default
     reductions, and the use of `%nonassoc'.  Delayed syntax error
     detection results in unexpected semantic actions, initiation of
     error recovery in the wrong syntactic context, and an incorrect
     list of expected tokens in a verbose syntax error message.  *Note
     LAC::.

Language construct
     One of the typical usage schemas of the language.  For example,
     one of the constructs of the C language is the `if' statement.
     *Note Languages and Context-Free Grammars: Language and Grammar.

Left associativity
     Operators having left associativity are analyzed from left to
     right: `a+b+c' first computes `a+b' and then combines with `c'.
     *Note Operator Precedence: Precedence.

Left recursion
     A rule whose result symbol is also its first component symbol; for
     example, `expseq1 : expseq1 ',' exp;'.  *Note Recursive Rules:
     Recursion.

Left-to-right parsing
     Parsing a sentence of a language by analyzing it token by token
     from left to right.  *Note The Bison Parser Algorithm: Algorithm.

Lexical analyzer (scanner)
     A function that reads an input stream and returns tokens one by
     one.  *Note The Lexical Analyzer Function `yylex': Lexical.

Lexical tie-in
     A flag, set by actions in the grammar rules, which alters the way
     tokens are parsed.  *Note Lexical Tie-ins::.

Literal string token
     A token which consists of two or more fixed characters.  *Note
     Symbols::.

Lookahead token
     A token already read but not yet shifted.  *Note Lookahead Tokens:
     Lookahead.

LALR(1)
     The class of context-free grammars that Bison (like most other
     parser generators) can handle by default; a subset of LR(1).
     *Note Mysterious Conflicts::.

LR(1)
     The class of context-free grammars in which at most one token of
     lookahead is needed to disambiguate the parsing of any piece of
     input.

Nonterminal symbol
     A grammar symbol standing for a grammatical construct that can be
     expressed through rules in terms of smaller constructs; in other
     words, a construct that is not a token.  *Note Symbols::.

Parser
     A function that recognizes valid sentences of a language by
     analyzing the syntax structure of a set of tokens passed to it
     from a lexical analyzer.

Postfix operator
     An arithmetic operator that is placed after the operands upon
     which it performs some operation.

Reduction
     Replacing a string of nonterminals and/or terminals with a single
     nonterminal, according to a grammar rule.  *Note The Bison Parser
     Algorithm: Algorithm.

Reentrant
     A reentrant subprogram is a subprogram which can be in invoked any
     number of times in parallel, without interference between the
     various invocations.  *Note A Pure (Reentrant) Parser: Pure Decl.

Reverse polish notation
     A language in which all operators are postfix operators.

Right recursion
     A rule whose result symbol is also its last component symbol; for
     example, `expseq1: exp ',' expseq1;'.  *Note Recursive Rules:
     Recursion.

Semantics
     In computer languages, the semantics are specified by the actions
     taken for each instance of the language, i.e., the meaning of each
     statement.  *Note Defining Language Semantics: Semantics.

Shift
     A parser is said to shift when it makes the choice of analyzing
     further input from the stream rather than reducing immediately some
     already-recognized rule.  *Note The Bison Parser Algorithm:
     Algorithm.

Single-character literal
     A single character that is recognized and interpreted as is.
     *Note From Formal Rules to Bison Input: Grammar in Bison.

Start symbol
     The nonterminal symbol that stands for a complete valid utterance
     in the language being parsed.  The start symbol is usually listed
     as the first nonterminal symbol in a language specification.
     *Note The Start-Symbol: Start Decl.

Symbol table
     A data structure where symbol names and associated data are stored
     during parsing to allow for recognition and use of existing
     information in repeated uses of a symbol.  *Note Multi-function
     Calc::.

Syntax error
     An error encountered during parsing of an input stream due to
     invalid syntax.  *Note Error Recovery::.

Token
     A basic, grammatically indivisible unit of a language.  The symbol
     that describes a token in the grammar is a terminal symbol.  The
     input of the Bison parser is a stream of tokens which comes from
     the lexical analyzer.  *Note Symbols::.

Terminal symbol
     A grammar symbol that has no rules in the grammar and therefore is
     grammatically indivisible.  The piece of text it represents is a
     token.  *Note Languages and Context-Free Grammars: Language and
     Grammar.

Unreachable state
     A parser state to which there does not exist a sequence of
     transitions from the parser's start state.  A state can become
     unreachable during conflict resolution.  *Note Unreachable
     States::.

\1f
File: bison.info,  Node: Copying This Manual,  Next: Bibliography,  Prev: Glossary,  Up: Top

Annexe C Copying This Manual
****************************

                     Version 1.3, 3 November 2008

     Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
     `http://fsf.org/'

     Everyone is permitted to copy and distribute verbatim copies
     of this license document, but changing it is not allowed.

  0. PREAMBLE

     The purpose of this License is to make a manual, textbook, or other
     functional and useful document "free" in the sense of freedom: to
     assure everyone the effective freedom to copy and redistribute it,
     with or without modifying it, either commercially or
     noncommercially.  Secondarily, this License preserves for the
     author and publisher a way to get credit for their work, while not
     being considered responsible for modifications made by others.

     This License is a kind of "copyleft", which means that derivative
     works of the document must themselves be free in the same sense.
     It complements the GNU General Public License, which is a copyleft
     license designed for free software.

     We have designed this License in order to use it for manuals for
     free software, because free software needs free documentation: a
     free program should come with manuals providing the same freedoms
     that the software does.  But this License is not limited to
     software manuals; it can be used for any textual work, regardless
     of subject matter or whether it is published as a printed book.
     We recommend this License principally for works whose purpose is
     instruction or reference.

  1. APPLICABILITY AND DEFINITIONS

     This License applies to any manual or other work, in any medium,
     that contains a notice placed by the copyright holder saying it
     can be distributed under the terms of this License.  Such a notice
     grants a world-wide, royalty-free license, unlimited in duration,
     to use that work under the conditions stated herein.  The
     "Document", below, refers to any such manual or work.  Any member
     of the public is a licensee, and is addressed as "you".  You
     accept the license if you copy, modify or distribute the work in a
     way requiring permission under copyright law.

     A "Modified Version" of the Document means any work containing the
     Document or a portion of it, either copied verbatim, or with
     modifications and/or translated into another language.

     A "Secondary Section" is a named appendix or a front-matter section
     of the Document that deals exclusively with the relationship of the
     publishers or authors of the Document to the Document's overall
     subject (or to related matters) and contains nothing that could
     fall directly within that overall subject.  (Thus, if the Document
     is in part a textbook of mathematics, a Secondary Section may not
     explain any mathematics.)  The relationship could be a matter of
     historical connection with the subject or with related matters, or
     of legal, commercial, philosophical, ethical or political position
     regarding them.

     The "Invariant Sections" are certain Secondary Sections whose
     titles are designated, as being those of Invariant Sections, in
     the notice that says that the Document is released under this
     License.  If a section does not fit the above definition of
     Secondary then it is not allowed to be designated as Invariant.
     The Document may contain zero Invariant Sections.  If the Document
     does not identify any Invariant Sections then there are none.

     The "Cover Texts" are certain short passages of text that are
     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
     that says that the Document is released under this License.  A
     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
     be at most 25 words.

     A "Transparent" copy of the Document means a machine-readable copy,
     represented in a format whose specification is available to the
     general public, that is suitable for revising the document
     straightforwardly with generic text editors or (for images
     composed of pixels) generic paint programs or (for drawings) some
     widely available drawing editor, and that is suitable for input to
     text formatters or for automatic translation to a variety of
     formats suitable for input to text formatters.  A copy made in an
     otherwise Transparent file format whose markup, or absence of
     markup, has been arranged to thwart or discourage subsequent
     modification by readers is not Transparent.  An image format is
     not Transparent if used for any substantial amount of text.  A
     copy that is not "Transparent" is called "Opaque".

     Examples of suitable formats for Transparent copies include plain
     ASCII without markup, Texinfo input format, LaTeX input format,
     SGML or XML using a publicly available DTD, and
     standard-conforming simple HTML, PostScript or PDF designed for
     human modification.  Examples of transparent image formats include
     PNG, XCF and JPG.  Opaque formats include proprietary formats that
     can be read and edited only by proprietary word processors, SGML or
     XML for which the DTD and/or processing tools are not generally
     available, and the machine-generated HTML, PostScript or PDF
     produced by some word processors for output purposes only.

     The "Title Page" means, for a printed book, the title page itself,
     plus such following pages as are needed to hold, legibly, the
     material this License requires to appear in the title page.  For
     works in formats which do not have any title page as such, "Title
     Page" means the text near the most prominent appearance of the
     work's title, preceding the beginning of the body of the text.

     The "publisher" means any person or entity that distributes copies
     of the Document to the public.

     A section "Entitled XYZ" means a named subunit of the Document
     whose title either is precisely XYZ or contains XYZ in parentheses
     following text that translates XYZ in another language.  (Here XYZ
     stands for a specific section name mentioned below, such as
     "Acknowledgements", "Dedications", "Endorsements", or "History".)
     To "Preserve the Title" of such a section when you modify the
     Document means that it remains a section "Entitled XYZ" according
     to this definition.

     The Document may include Warranty Disclaimers next to the notice
     which states that this License applies to the Document.  These
     Warranty Disclaimers are considered to be included by reference in
     this License, but only as regards disclaiming warranties: any other
     implication that these Warranty Disclaimers may have is void and
     has no effect on the meaning of this License.

  2. VERBATIM COPYING

     You may copy and distribute the Document in any medium, either
     commercially or noncommercially, provided that this License, the
     copyright notices, and the license notice saying this License
     applies to the Document are reproduced in all copies, and that you
     add no other conditions whatsoever to those of this License.  You
     may not use technical measures to obstruct or control the reading
     or further copying of the copies you make or distribute.  However,
     you may accept compensation in exchange for copies.  If you
     distribute a large enough number of copies you must also follow
     the conditions in section 3.

     You may also lend copies, under the same conditions stated above,
     and you may publicly display copies.

  3. COPYING IN QUANTITY

     If you publish printed copies (or copies in media that commonly
     have printed covers) of the Document, numbering more than 100, and
     the Document's license notice requires Cover Texts, you must
     enclose the copies in covers that carry, clearly and legibly, all
     these Cover Texts: Front-Cover Texts on the front cover, and
     Back-Cover Texts on the back cover.  Both covers must also clearly
     and legibly identify you as the publisher of these copies.  The
     front cover must present the full title with all words of the
     title equally prominent and visible.  You may add other material
     on the covers in addition.  Copying with changes limited to the
     covers, as long as they preserve the title of the Document and
     satisfy these conditions, can be treated as verbatim copying in
     other respects.

     If the required texts for either cover are too voluminous to fit
     legibly, you should put the first ones listed (as many as fit
     reasonably) on the actual cover, and continue the rest onto
     adjacent pages.

     If you publish or distribute Opaque copies of the Document
     numbering more than 100, you must either include a
     machine-readable Transparent copy along with each Opaque copy, or
     state in or with each Opaque copy a computer-network location from
     which the general network-using public has access to download
     using public-standard network protocols a complete Transparent
     copy of the Document, free of added material.  If you use the
     latter option, you must take reasonably prudent steps, when you
     begin distribution of Opaque copies in quantity, to ensure that
     this Transparent copy will remain thus accessible at the stated
     location until at least one year after the last time you
     distribute an Opaque copy (directly or through your agents or
     retailers) of that edition to the public.

     It is requested, but not required, that you contact the authors of
     the Document well before redistributing any large number of
     copies, to give them a chance to provide you with an updated
     version of the Document.

  4. MODIFICATIONS

     You may copy and distribute a Modified Version of the Document
     under the conditions of sections 2 and 3 above, provided that you
     release the Modified Version under precisely this License, with
     the Modified Version filling the role of the Document, thus
     licensing distribution and modification of the Modified Version to
     whoever possesses a copy of it.  In addition, you must do these
     things in the Modified Version:

       A. Use in the Title Page (and on the covers, if any) a title
          distinct from that of the Document, and from those of
          previous versions (which should, if there were any, be listed
          in the History section of the Document).  You may use the
          same title as a previous version if the original publisher of
          that version gives permission.

       B. List on the Title Page, as authors, one or more persons or
          entities responsible for authorship of the modifications in
          the Modified Version, together with at least five of the
          principal authors of the Document (all of its principal
          authors, if it has fewer than five), unless they release you
          from this requirement.

       C. State on the Title page the name of the publisher of the
          Modified Version, as the publisher.

       D. Preserve all the copyright notices of the Document.

       E. Add an appropriate copyright notice for your modifications
          adjacent to the other copyright notices.

       F. Include, immediately after the copyright notices, a license
          notice giving the public permission to use the Modified
          Version under the terms of this License, in the form shown in
          the Addendum below.

       G. Preserve in that license notice the full lists of Invariant
          Sections and required Cover Texts given in the Document's
          license notice.

       H. Include an unaltered copy of this License.

       I. Preserve the section Entitled "History", Preserve its Title,
          and add to it an item stating at least the title, year, new
          authors, and publisher of the Modified Version as given on
          the Title Page.  If there is no section Entitled "History" in
          the Document, create one stating the title, year, authors,
          and publisher of the Document as given on its Title Page,
          then add an item describing the Modified Version as stated in
          the previous sentence.

       J. Preserve the network location, if any, given in the Document
          for public access to a Transparent copy of the Document, and
          likewise the network locations given in the Document for
          previous versions it was based on.  These may be placed in
          the "History" section.  You may omit a network location for a
          work that was published at least four years before the
          Document itself, or if the original publisher of the version
          it refers to gives permission.

       K. For any section Entitled "Acknowledgements" or "Dedications",
          Preserve the Title of the section, and preserve in the
          section all the substance and tone of each of the contributor
          acknowledgements and/or dedications given therein.

       L. Preserve all the Invariant Sections of the Document,
          unaltered in their text and in their titles.  Section numbers
          or the equivalent are not considered part of the section
          titles.

       M. Delete any section Entitled "Endorsements".  Such a section
          may not be included in the Modified Version.

       N. Do not retitle any existing section to be Entitled
          "Endorsements" or to conflict in title with any Invariant
          Section.

       O. Preserve any Warranty Disclaimers.

     If the Modified Version includes new front-matter sections or
     appendices that qualify as Secondary Sections and contain no
     material copied from the Document, you may at your option
     designate some or all of these sections as invariant.  To do this,
     add their titles to the list of Invariant Sections in the Modified
     Version's license notice.  These titles must be distinct from any
     other section titles.

     You may add a section Entitled "Endorsements", provided it contains
     nothing but endorsements of your Modified Version by various
     parties--for example, statements of peer review or that the text
     has been approved by an organization as the authoritative
     definition of a standard.

     You may add a passage of up to five words as a Front-Cover Text,
     and a passage of up to 25 words as a Back-Cover Text, to the end
     of the list of Cover Texts in the Modified Version.  Only one
     passage of Front-Cover Text and one of Back-Cover Text may be
     added by (or through arrangements made by) any one entity.  If the
     Document already includes a cover text for the same cover,
     previously added by you or by arrangement made by the same entity
     you are acting on behalf of, you may not add another; but you may
     replace the old one, on explicit permission from the previous
     publisher that added the old one.

     The author(s) and publisher(s) of the Document do not by this
     License give permission to use their names for publicity for or to
     assert or imply endorsement of any Modified Version.

  5. COMBINING DOCUMENTS

     You may combine the Document with other documents released under
     this License, under the terms defined in section 4 above for
     modified versions, provided that you include in the combination
     all of the Invariant Sections of all of the original documents,
     unmodified, and list them all as Invariant Sections of your
     combined work in its license notice, and that you preserve all
     their Warranty Disclaimers.

     The combined work need only contain one copy of this License, and
     multiple identical Invariant Sections may be replaced with a single
     copy.  If there are multiple Invariant Sections with the same name
     but different contents, make the title of each such section unique
     by adding at the end of it, in parentheses, the name of the
     original author or publisher of that section if known, or else a
     unique number.  Make the same adjustment to the section titles in
     the list of Invariant Sections in the license notice of the
     combined work.

     In the combination, you must combine any sections Entitled
     "History" in the various original documents, forming one section
     Entitled "History"; likewise combine any sections Entitled
     "Acknowledgements", and any sections Entitled "Dedications".  You
     must delete all sections Entitled "Endorsements."

  6. COLLECTIONS OF DOCUMENTS

     You may make a collection consisting of the Document and other
     documents released under this License, and replace the individual
     copies of this License in the various documents with a single copy
     that is included in the collection, provided that you follow the
     rules of this License for verbatim copying of each of the
     documents in all other respects.

     You may extract a single document from such a collection, and
     distribute it individually under this License, provided you insert
     a copy of this License into the extracted document, and follow
     this License in all other respects regarding verbatim copying of
     that document.

  7. AGGREGATION WITH INDEPENDENT WORKS

     A compilation of the Document or its derivatives with other
     separate and independent documents or works, in or on a volume of
     a storage or distribution medium, is called an "aggregate" if the
     copyright resulting from the compilation is not used to limit the
     legal rights of the compilation's users beyond what the individual
     works permit.  When the Document is included in an aggregate, this
     License does not apply to the other works in the aggregate which
     are not themselves derivative works of the Document.

     If the Cover Text requirement of section 3 is applicable to these
     copies of the Document, then if the Document is less than one half
     of the entire aggregate, the Document's Cover Texts may be placed
     on covers that bracket the Document within the aggregate, or the
     electronic equivalent of covers if the Document is in electronic
     form.  Otherwise they must appear on printed covers that bracket
     the whole aggregate.

  8. TRANSLATION

     Translation is considered a kind of modification, so you may
     distribute translations of the Document under the terms of section
     4.  Replacing Invariant Sections with translations requires special
     permission from their copyright holders, but you may include
     translations of some or all Invariant Sections in addition to the
     original versions of these Invariant Sections.  You may include a
     translation of this License, and all the license notices in the
     Document, and any Warranty Disclaimers, provided that you also
     include the original English version of this License and the
     original versions of those notices and disclaimers.  In case of a
     disagreement between the translation and the original version of
     this License or a notice or disclaimer, the original version will
     prevail.

     If a section in the Document is Entitled "Acknowledgements",
     "Dedications", or "History", the requirement (section 4) to
     Preserve its Title (section 1) will typically require changing the
     actual title.

  9. TERMINATION

     You may not copy, modify, sublicense, or distribute the Document
     except as expressly provided under this License.  Any attempt
     otherwise to copy, modify, sublicense, or distribute it is void,
     and will automatically terminate your rights under this License.

     However, if you cease all violation of this License, then your
     license from a particular copyright holder is reinstated (a)
     provisionally, unless and until the copyright holder explicitly
     and finally terminates your license, and (b) permanently, if the
     copyright holder fails to notify you of the violation by some
     reasonable means prior to 60 days after the cessation.

     Moreover, your license from a particular copyright holder is
     reinstated permanently if the copyright holder notifies you of the
     violation by some reasonable means, this is the first time you have
     received notice of violation of this License (for any work) from
     that copyright holder, and you cure the violation prior to 30 days
     after your receipt of the notice.

     Termination of your rights under this section does not terminate
     the licenses of parties who have received copies or rights from
     you under this License.  If your rights have been terminated and
     not permanently reinstated, receipt of a copy of some or all of
     the same material does not give you any rights to use it.

 10. FUTURE REVISIONS OF THIS LICENSE

     The Free Software Foundation may publish new, revised versions of
     the GNU Free Documentation License from time to time.  Such new
     versions will be similar in spirit to the present version, but may
     differ in detail to address new problems or concerns.  See
     `http://www.gnu.org/copyleft/'.

     Each version of the License is given a distinguishing version
     number.  If the Document specifies that a particular numbered
     version of this License "or any later version" applies to it, you
     have the option of following the terms and conditions either of
     that specified version or of any later version that has been
     published (not as a draft) by the Free Software Foundation.  If
     the Document does not specify a version number of this License,
     you may choose any version ever published (not as a draft) by the
     Free Software Foundation.  If the Document specifies that a proxy
     can decide which future versions of this License can be used, that
     proxy's public statement of acceptance of a version permanently
     authorizes you to choose that version for the Document.

 11. RELICENSING

     "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
     World Wide Web server that publishes copyrightable works and also
     provides prominent facilities for anybody to edit those works.  A
     public wiki that anybody can edit is an example of such a server.
     A "Massive Multiauthor Collaboration" (or "MMC") contained in the
     site means any set of copyrightable works thus published on the MMC
     site.

     "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
     license published by Creative Commons Corporation, a not-for-profit
     corporation with a principal place of business in San Francisco,
     California, as well as future copyleft versions of that license
     published by that same organization.

     "Incorporate" means to publish or republish a Document, in whole or
     in part, as part of another Document.

     An MMC is "eligible for relicensing" if it is licensed under this
     License, and if all works that were first published under this
     License somewhere other than this MMC, and subsequently
     incorporated in whole or in part into the MMC, (1) had no cover
     texts or invariant sections, and (2) were thus incorporated prior
     to November 1, 2008.

     The operator of an MMC Site may republish an MMC contained in the
     site under CC-BY-SA on the same site at any time before August 1,
     2009, provided the MMC is eligible for relicensing.


ADDENDUM: How to use this License for your documents
====================================================

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:

       Copyright (C)  YEAR  YOUR NAME.
       Permission is granted to copy, distribute and/or modify this document
       under the terms of the GNU Free Documentation License, Version 1.3
       or any later version published by the Free Software Foundation;
       with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
       Texts.  A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.

   If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the "with...Texts." line with this:

         with the Invariant Sections being LIST THEIR TITLES, with
         the Front-Cover Texts being LIST, and with the Back-Cover Texts
         being LIST.

   If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

   If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License, to
permit their use in free software.

\1f
File: bison.info,  Node: Bibliography,  Next: Index of Terms,  Prev: Copying This Manual,  Up: Top

Bibliography
************

[Denny 2008]
     Joel E. Denny and Brian A. Malloy, IELR(1): Practical LR(1) Parser
     Tables for Non-LR(1) Grammars with Conflict Resolution, in
     `Proceedings of the 2008 ACM Symposium on Applied Computing'
     (SAC'08), ACM, New York, NY, USA, pp. 240-245.
     `http://dx.doi.org/10.1145/1363686.1363747'

[Denny 2010 May]
     Joel E. Denny, PSLR(1): Pseudo-Scannerless Minimal LR(1) for the
     Deterministic Parsing of Composite Languages, Ph.D. Dissertation,
     Clemson University, Clemson, SC, USA (May 2010).
     `http://proquest.umi.com/pqdlink?did=2041473591&Fmt=7&clientId=79356&RQT=309&VName=PQD'

[Denny 2010 November]
     Joel E. Denny and Brian A. Malloy, The IELR(1) Algorithm for
     Generating Minimal LR(1) Parser Tables for Non-LR(1) Grammars with
     Conflict Resolution, in `Science of Computer Programming', Vol.
     75, Issue 11 (November 2010), pp. 943-979.
     `http://dx.doi.org/10.1016/j.scico.2009.08.001'

[DeRemer 1982]
     Frank DeRemer and Thomas Pennello, Efficient Computation of LALR(1)
     Look-Ahead Sets, in `ACM Transactions on Programming Languages and
     Systems', Vol. 4, No. 4 (October 1982), pp.  615-649.
     `http://dx.doi.org/10.1145/69622.357187'

[Knuth 1965]
     Donald E. Knuth, On the Translation of Languages from Left to
     Right, in `Information and Control', Vol. 8, Issue 6 (December
     1965), pp.  607-639.
     `http://dx.doi.org/10.1016/S0019-9958(65)90426-2'

[Scott 2000]
     Elizabeth Scott, Adrian Johnstone, and Shamsa Sadaf Hussain,
     `Tomita-Style Generalised LR Parsers', Royal Holloway, University
     of London, Department of Computer Science, TR-00-12 (December
     2000).
     `http://www.cs.rhul.ac.uk/research/languages/publications/tomita_style_1.ps'

\1f
File: bison.info,  Node: Index of Terms,  Prev: Bibliography,  Up: Top

Index of Terms
**************

\0\b[index\0\b]
* Menu:

* $ <1>:                                 Action Features.     (line  14)
* $ <2>:                                 Table of Symbols.    (line  31)
* $ <3>:                                 Java Action Features.
                                                              (line  13)
* $:                                     Table of Symbols.    (line  35)
* $$ <1>:                                Java Action Features.
                                                              (line  21)
* $$ <2>:                                Actions.             (line   6)
* $$ <3>:                                Action Features.     (line  10)
* $$:                                    Table of Symbols.    (line  23)
* $< <1>:                                Action Features.     (line  23)
* $<:                                    Java Action Features.
                                                              (line  17)
* $[NAME]:                               Actions.             (line   6)
* $accept:                               Table of Symbols.    (line  81)
* $end:                                  Table of Symbols.    (line 119)
* $N:                                    Actions.             (line   6)
* $NAME:                                 Actions.             (line   6)
* $undefined:                            Table of Symbols.    (line 240)
* % <1>:                                 Table of Symbols.    (line  44)
* %:                                     Java Declarations Summary.
                                                              (line  53)
* %% <1>:                                Table of Symbols.    (line  39)
* %%:                                    Java Declarations Summary.
                                                              (line  49)
* %code <1>:                             Decl Summary.        (line  47)
* %code <2>:                             Java Declarations Summary.
                                                              (line  37)
* %code <3>:                             %code Summary.       (line   6)
* %code <4>:                             Prologue Alternatives.
                                                              (line   6)
* %code <5>:                             Table of Symbols.    (line  86)
* %code <6>:                             %code Summary.       (line  27)
* %code <7>:                             Table of Symbols.    (line  87)
* %code:                                 Calc++ Parser.       (line  65)
* %code imports <1>:                     Java Declarations Summary.
                                                              (line  41)
* %code imports:                         %code Summary.       (line  83)
* %code lexer:                           Java Declarations Summary.
                                                              (line  45)
* %code provides <1>:                    Decl Summary.        (line  95)
* %code provides <2>:                    %code Summary.       (line  55)
* %code provides:                        Prologue Alternatives.
                                                              (line   6)
* %code requires <1>:                    Prologue Alternatives.
                                                              (line   6)
* %code requires <2>:                    Decl Summary.        (line  95)
* %code requires <3>:                    %code Summary.       (line  41)
* %code requires:                        Calc++ Parser.       (line  17)
* %code top <1>:                         Prologue Alternatives.
                                                              (line   6)
* %code top:                             %code Summary.       (line  67)
* %debug <1>:                            Table of Symbols.    (line  92)
* %debug <2>:                            Enabling Traces.     (line  28)
* %debug:                                Decl Summary.        (line  52)
* %define <1>:                           Decl Summary.        (line  61)
* %define <2>:                           %define Summary.     (line  15)
* %define <3>:                           Decl Summary.        (line  59)
* %define <4>:                           Table of Symbols.    (line  95)
* %define:                               %define Summary.     (line  14)
* %define abstract:                      Java Declarations Summary.
                                                              (line  57)
* %define api.prefix:                    %define Summary.     (line  49)
* %define api.pure <1>:                  %define Summary.     (line  62)
* %define api.pure:                      Pure Decl.           (line   6)
* %define api.push-pull <1>:             Push Decl.           (line   6)
* %define api.push-pull:                 %define Summary.     (line  73)
* %define extends:                       Java Declarations Summary.
                                                              (line  61)
* %define final:                         Java Declarations Summary.
                                                              (line  65)
* %define implements:                    Java Declarations Summary.
                                                              (line  69)
* %define lex_throws:                    Java Declarations Summary.
                                                              (line  73)
* %define location_type:                 Java Declarations Summary.
                                                              (line  78)
* %define lr.default-reductions <1>:     Default Reductions.  (line   6)
* %define lr.default-reductions:         %define Summary.     (line  86)
* %define lr.default-reductions WHERE:   Default Reductions.  (line  84)
* %define lr.keep-unreachable-states <1>: %define Summary.    (line 103)
* %define lr.keep-unreachable-states:    Unreachable States.  (line   6)
* %define lr.keep-unreachable-states VALUE: Unreachable States.
                                                              (line  17)
* %define lr.type <1>:                   %define Summary.     (line 114)
* %define lr.type:                       LR Table Construction.
                                                              (line   6)
* %define lr.type TYPE:                  LR Table Construction.
                                                              (line  24)
* %define namespace <1>:                 %define Summary.     (line 126)
* %define namespace:                     C++ Bison Interface. (line  10)
* %define package:                       Java Declarations Summary.
                                                              (line  84)
* %define parse.lac <1>:                 LAC.                 (line   6)
* %define parse.lac:                     %define Summary.     (line 166)
* %define parse.lac VALUE:               LAC.                 (line  29)
* %define parser_class_name:             Java Declarations Summary.
                                                              (line  88)
* %define position_type:                 Java Declarations Summary.
                                                              (line  92)
* %define public:                        Java Declarations Summary.
                                                              (line  97)
* %define strictfp:                      Java Declarations Summary.
                                                              (line 105)
* %define stype:                         Java Declarations Summary.
                                                              (line 101)
* %define throws:                        Java Declarations Summary.
                                                              (line 109)
* %defines <1>:                          Decl Summary.        (line  65)
* %defines:                              Table of Symbols.    (line 101)
* %destructor <1>:                       Table of Symbols.    (line 109)
* %destructor <2>:                       Decl Summary.        (line 102)
* %destructor <3>:                       Destructor Decl.     (line   6)
* %destructor:                           Mid-Rule Actions.    (line  59)
* %dprec <1>:                            Merging GLR Parses.  (line   6)
* %dprec:                                Table of Symbols.    (line 114)
* %error-verbose <1>:                    Error Reporting.     (line  17)
* %error-verbose:                        Table of Symbols.    (line 133)
* %expect <1>:                           Decl Summary.        (line  38)
* %expect:                               Expect Decl.         (line   6)
* %expect-rr <1>:                        Expect Decl.         (line   6)
* %expect-rr:                            Simple GLR Parsers.  (line   6)
* %file-prefix <1>:                      Table of Symbols.    (line 137)
* %file-prefix:                          Decl Summary.        (line 107)
* %glr-parser <1>:                       Simple GLR Parsers.  (line   6)
* %glr-parser <2>:                       Table of Symbols.    (line 141)
* %glr-parser:                           GLR Parsers.         (line   6)
* %initial-action <1>:                   Table of Symbols.    (line 145)
* %initial-action:                       Initial Action Decl. (line  11)
* %language <1>:                         Table of Symbols.    (line 149)
* %language:                             Decl Summary.        (line 111)
* %language "Java":                      Java Declarations Summary.
                                                              (line  10)
* %left <1>:                             Table of Symbols.    (line 153)
* %left <2>:                             Using Precedence.    (line   6)
* %left:                                 Decl Summary.        (line  21)
* %lex-param <1>:                        Table of Symbols.    (line 157)
* %lex-param <2>:                        Java Declarations Summary.
                                                              (line  13)
* %lex-param:                            Pure Calling.        (line  31)
* %locations:                            Decl Summary.        (line 119)
* %merge <1>:                            Merging GLR Parses.  (line   6)
* %merge:                                Table of Symbols.    (line 162)
* %name-prefix <1>:                      Java Declarations Summary.
                                                              (line  19)
* %name-prefix:                          Table of Symbols.    (line 169)
* %no-lines <1>:                         Table of Symbols.    (line 186)
* %no-lines:                             Decl Summary.        (line 126)
* %nonassoc <1>:                         Decl Summary.        (line  25)
* %nonassoc <2>:                         Table of Symbols.    (line 190)
* %nonassoc <3>:                         Default Reductions.  (line   6)
* %nonassoc <4>:                         LR Table Construction.
                                                              (line 103)
* %nonassoc:                             Using Precedence.    (line   6)
* %output <1>:                           Table of Symbols.    (line 194)
* %output:                               Decl Summary.        (line 135)
* %parse-param <1>:                      Parser Function.     (line  36)
* %parse-param <2>:                      Java Declarations Summary.
                                                              (line  24)
* %parse-param <3>:                      Parser Function.     (line  36)
* %parse-param:                          Table of Symbols.    (line 198)
* %prec <1>:                             Contextual Precedence.
                                                              (line   6)
* %prec:                                 Table of Symbols.    (line 203)
* %printer:                              Printer Decl.        (line   6)
* %pure-parser <1>:                      Table of Symbols.    (line 207)
* %pure-parser:                          Decl Summary.        (line 138)
* %require <1>:                          Require Decl.        (line   6)
* %require <2>:                          Decl Summary.        (line 143)
* %require:                              Table of Symbols.    (line 212)
* %right <1>:                            Using Precedence.    (line   6)
* %right <2>:                            Table of Symbols.    (line 216)
* %right:                                Decl Summary.        (line  17)
* %skeleton <1>:                         Table of Symbols.    (line 220)
* %skeleton:                             Decl Summary.        (line 147)
* %start <1>:                            Start Decl.          (line   6)
* %start <2>:                            Decl Summary.        (line  34)
* %start:                                Table of Symbols.    (line 224)
* %token <1>:                            Decl Summary.        (line  13)
* %token <2>:                            Java Declarations Summary.
                                                              (line  29)
* %token <3>:                            Table of Symbols.    (line 228)
* %token:                                Token Decl.          (line   6)
* %token-table <1>:                      Decl Summary.        (line 155)
* %token-table:                          Table of Symbols.    (line 232)
* %type <1>:                             Type Decl.           (line   6)
* %type <2>:                             Table of Symbols.    (line 236)
* %type <3>:                             Decl Summary.        (line  30)
* %type:                                 Java Declarations Summary.
                                                              (line  33)
* %union <1>:                            Decl Summary.        (line   9)
* %union <2>:                            Union Decl.          (line   6)
* %union:                                Table of Symbols.    (line 245)
* %verbose:                              Decl Summary.        (line 188)
* %yacc:                                 Decl Summary.        (line 194)
* /*:                                    Table of Symbols.    (line  49)
* ::                                     Table of Symbols.    (line  52)
* ;:                                     Table of Symbols.    (line  56)
* <*> <1>:                               Printer Decl.        (line   6)
* <*> <2>:                               Table of Symbols.    (line  63)
* <*>:                                   Destructor Decl.     (line   6)
* <> <1>:                                Printer Decl.        (line   6)
* <> <2>:                                Table of Symbols.    (line  72)
* <>:                                    Destructor Decl.     (line   6)
* @$ <1>:                                Table of Symbols.    (line   7)
* @$ <2>:                                Actions and Locations.
                                                              (line   6)
* @$ <3>:                                Action Features.     (line  98)
* @$:                                    Java Action Features.
                                                              (line  39)
* @[:                                    Table of Symbols.    (line  19)
* @[NAME]:                               Actions and Locations.
                                                              (line   6)
* @N <1>:                                Action Features.     (line 104)
* @N <2>:                                Actions and Locations.
                                                              (line   6)
* @N <3>:                                Java Action Features.
                                                              (line  35)
* @N:                                    Table of Symbols.    (line  11)
* @NAME <1>:                             Actions and Locations.
                                                              (line   6)
* @NAME:                                 Table of Symbols.    (line  15)
* abstract syntax tree:                  Implementing Gotos/Loops.
                                                              (line  17)
* accepting state:                       Understanding.       (line 178)
* action:                                Actions.             (line   6)
* action data types:                     Action Types.        (line   6)
* action features summary:               Action Features.     (line   6)
* actions in mid-rule <1>:               Destructor Decl.     (line  88)
* actions in mid-rule:                   Mid-Rule Actions.    (line   6)
* actions, location:                     Actions and Locations.
                                                              (line   6)
* actions, semantic:                     Semantic Actions.    (line   6)
* additional C code section:             Epilogue.            (line   6)
* algorithm of parser:                   Algorithm.           (line   6)
* ambiguous grammars <1>:                Generalized LR Parsing.
                                                              (line   6)
* ambiguous grammars:                    Language and Grammar.
                                                              (line  34)
* associativity:                         Why Precedence.      (line  34)
* AST:                                   Implementing Gotos/Loops.
                                                              (line  17)
* Backus-Naur form:                      Language and Grammar.
                                                              (line  16)
* begin of Location:                     Java Location Values.
                                                              (line  21)
* begin of location:                     C++ location.        (line  22)
* Bison declaration summary:             Decl Summary.        (line   6)
* Bison declarations:                    Declarations.        (line   6)
* Bison declarations (introduction):     Bison Declarations.  (line   6)
* Bison grammar:                         Grammar in Bison.    (line   6)
* Bison invocation:                      Invocation.          (line   6)
* Bison parser:                          Bison Parser.        (line   6)
* Bison parser algorithm:                Algorithm.           (line   6)
* Bison symbols, table of:               Table of Symbols.    (line   6)
* Bison utility:                         Bison Parser.        (line   6)
* bison-i18n.m4:                         Internationalization.
                                                              (line  20)
* bison-po:                              Internationalization.
                                                              (line   6)
* BISON_I18N:                            Internationalization.
                                                              (line  27)
* BISON_LOCALEDIR:                       Internationalization.
                                                              (line  27)
* BNF:                                   Language and Grammar.
                                                              (line  16)
* braced code:                           Rules.               (line  29)
* C code, section for additional:        Epilogue.            (line   6)
* C-language interface:                  Interface.           (line   6)
* calc:                                  Infix Calc.          (line   6)
* calculator, infix notation:            Infix Calc.          (line   6)
* calculator, location tracking:         Location Tracking Calc.
                                                              (line   6)
* calculator, multi-function:            Multi-function Calc. (line   6)
* calculator, simple:                    RPN Calc.            (line   6)
* canonical LR <1>:                      Mysterious Conflicts.
                                                              (line  45)
* canonical LR:                          LR Table Construction.
                                                              (line   6)
* character token:                       Symbols.             (line  37)
* column of position:                    C++ position.        (line  29)
* columns on location:                   C++ location.        (line  26)
* columns on position:                   C++ position.        (line  32)
* compiling the parser:                  Rpcalc Compile.      (line   6)
* conflicts <1>:                         Shift/Reduce.        (line   6)
* conflicts <2>:                         Merging GLR Parses.  (line   6)
* conflicts <3>:                         Simple GLR Parsers.  (line   6)
* conflicts:                             GLR Parsers.         (line   6)
* conflicts, reduce/reduce:              Reduce/Reduce.       (line   6)
* conflicts, suppressing warnings of:    Expect Decl.         (line   6)
* consistent states:                     Default Reductions.  (line  17)
* context-dependent precedence:          Contextual Precedence.
                                                              (line   6)
* context-free grammar:                  Language and Grammar.
                                                              (line   6)
* controlling function:                  Rpcalc Main.         (line   6)
* core, item set:                        Understanding.       (line 125)
* dangling else:                         Shift/Reduce.        (line   6)
* data type of locations:                Location Type.       (line   6)
* data types in actions:                 Action Types.        (line   6)
* data types of semantic values:         Value Type.          (line   6)
* debug_level on parser:                 C++ Parser Interface.
                                                              (line  38)
* debug_stream on parser:                C++ Parser Interface.
                                                              (line  33)
* debugging:                             Tracing.             (line   6)
* declaration summary:                   Decl Summary.        (line   6)
* declarations:                          Prologue.            (line   6)
* declarations section:                  Prologue.            (line   6)
* declarations, Bison:                   Declarations.        (line   6)
* declarations, Bison (introduction):    Bison Declarations.  (line   6)
* declaring literal string tokens:       Token Decl.          (line   6)
* declaring operator precedence:         Precedence Decl.     (line   6)
* declaring the start symbol:            Start Decl.          (line   6)
* declaring token type names:            Token Decl.          (line   6)
* declaring value types:                 Union Decl.          (line   6)
* declaring value types, nonterminals:   Type Decl.           (line   6)
* default action:                        Actions.             (line  62)
* default data type:                     Value Type.          (line   6)
* default location type:                 Location Type.       (line   6)
* default reductions:                    Default Reductions.  (line   6)
* default stack limit:                   Memory Management.   (line  30)
* default start symbol:                  Start Decl.          (line   6)
* defaulted states:                      Default Reductions.  (line  17)
* deferred semantic actions:             GLR Semantic Actions.
                                                              (line   6)
* defining language semantics:           Semantics.           (line   6)
* delayed syntax error detection <1>:    LR Table Construction.
                                                              (line 103)
* delayed syntax error detection:        Default Reductions.  (line  43)
* delayed yylex invocations:             Default Reductions.  (line  17)
* discarded symbols:                     Destructor Decl.     (line  98)
* discarded symbols, mid-rule actions:   Mid-Rule Actions.    (line  59)
* else, dangling:                        Shift/Reduce.        (line   6)
* end of location:                       C++ location.        (line  23)
* end of Location:                       Java Location Values.
                                                              (line  22)
* epilogue:                              Epilogue.            (line   6)
* error <1>:                             Error Recovery.      (line  20)
* error:                                 Table of Symbols.    (line 123)
* error on parser:                       C++ Parser Interface.
                                                              (line  44)
* error recovery:                        Error Recovery.      (line   6)
* error recovery, mid-rule actions:      Mid-Rule Actions.    (line  59)
* error recovery, simple:                Simple Error Recovery.
                                                              (line   6)
* error reporting function:              Error Reporting.     (line   6)
* error reporting routine:               Rpcalc Error.        (line   6)
* examples, simple:                      Examples.            (line   6)
* exercises:                             Exercises.           (line   6)
* file format:                           Grammar Layout.      (line   6)
* file of position:                      C++ position.        (line  17)
* finite-state machine:                  Parser States.       (line   6)
* formal grammar:                        Grammar in Bison.    (line   6)
* format of grammar file:                Grammar Layout.      (line   6)
* freeing discarded symbols:             Destructor Decl.     (line   6)
* frequently asked questions:            FAQ.                 (line   6)
* generalized LR (GLR) parsing <1>:      Language and Grammar.
                                                              (line  34)
* generalized LR (GLR) parsing <2>:      GLR Parsers.         (line   6)
* generalized LR (GLR) parsing:          Generalized LR Parsing.
                                                              (line   6)
* generalized LR (GLR) parsing, ambiguous grammars: Merging GLR Parses.
                                                              (line   6)
* generalized LR (GLR) parsing, unambiguous grammars: Simple GLR Parsers.
                                                              (line   6)
* getDebugLevel on YYParser:             Java Parser Interface.
                                                              (line  67)
* getDebugStream on YYParser:            Java Parser Interface.
                                                              (line  62)
* getEndPos on Lexer:                    Java Scanner Interface.
                                                              (line  39)
* getLVal on Lexer:                      Java Scanner Interface.
                                                              (line  47)
* getStartPos on Lexer:                  Java Scanner Interface.
                                                              (line  38)
* gettext:                               Internationalization.
                                                              (line   6)
* glossary:                              Glossary.            (line   6)
* GLR parsers and inline:                Compiler Requirements.
                                                              (line   6)
* GLR parsers and yychar:                GLR Semantic Actions.
                                                              (line  10)
* GLR parsers and yyclearin:             GLR Semantic Actions.
                                                              (line  18)
* GLR parsers and YYERROR:               GLR Semantic Actions.
                                                              (line  28)
* GLR parsers and yylloc:                GLR Semantic Actions.
                                                              (line  10)
* GLR parsers and YYLLOC_DEFAULT:        Location Default Action.
                                                              (line   6)
* GLR parsers and yylval:                GLR Semantic Actions.
                                                              (line  10)
* GLR parsing <1>:                       Generalized LR Parsing.
                                                              (line   6)
* GLR parsing <2>:                       GLR Parsers.         (line   6)
* GLR parsing:                           Language and Grammar.
                                                              (line  34)
* GLR parsing, ambiguous grammars:       Merging GLR Parses.  (line   6)
* GLR parsing, unambiguous grammars:     Simple GLR Parsers.  (line   6)
* GLR with LALR:                         LR Table Construction.
                                                              (line  65)
* grammar file:                          Grammar Layout.      (line   6)
* grammar rule syntax:                   Rules.               (line   6)
* grammar rules section:                 Grammar Rules.       (line   6)
* grammar, Bison:                        Grammar in Bison.    (line   6)
* grammar, context-free:                 Language and Grammar.
                                                              (line   6)
* grouping, syntactic:                   Language and Grammar.
                                                              (line  48)
* i18n:                                  Internationalization.
                                                              (line   6)
* IELR <1>:                              LR Table Construction.
                                                              (line   6)
* IELR:                                  Mysterious Conflicts.
                                                              (line  45)
* IELR grammars:                         Language and Grammar.
                                                              (line  22)
* infix notation calculator:             Infix Calc.          (line   6)
* initialize on location:                C++ location.        (line  19)
* initialize on position:                C++ position.        (line  14)
* inline:                                Compiler Requirements.
                                                              (line   6)
* interface:                             Interface.           (line   6)
* internationalization:                  Internationalization.
                                                              (line   6)
* introduction:                          Introduction.        (line   6)
* invoking Bison:                        Invocation.          (line   6)
* item:                                  Understanding.       (line 103)
* item set core:                         Understanding.       (line 125)
* kernel, item set:                      Understanding.       (line 125)
* LAC <1>:                               LR Table Construction.
                                                              (line 103)
* LAC <2>:                               Default Reductions.  (line  54)
* LAC:                                   LAC.                 (line   6)
* LALR <1>:                              Mysterious Conflicts.
                                                              (line  33)
* LALR:                                  LR Table Construction.
                                                              (line   6)
* LALR grammars:                         Language and Grammar.
                                                              (line  22)
* language semantics, defining:          Semantics.           (line   6)
* layout of Bison grammar:               Grammar Layout.      (line   6)
* left recursion:                        Recursion.           (line  17)
* lex-param:                             Pure Calling.        (line  31)
* lexical analyzer:                      Lexical.             (line   6)
* lexical analyzer, purpose:             Bison Parser.        (line   6)
* lexical analyzer, writing:             Rpcalc Lexer.        (line   6)
* lexical tie-in:                        Lexical Tie-ins.     (line   6)
* line of position:                      C++ position.        (line  23)
* lines on location:                     C++ location.        (line  27)
* lines on position:                     C++ position.        (line  26)
* literal string token:                  Symbols.             (line  59)
* literal token:                         Symbols.             (line  37)
* location <1>:                          Tracking Locations.  (line   6)
* location:                              Locations.           (line   6)
* location actions:                      Actions and Locations.
                                                              (line   6)
* Location on Location:                  Java Location Values.
                                                              (line  29)
* location on location:                  C++ location.        (line   8)
* Location on Location:                  Java Location Values.
                                                              (line  25)
* location tracking calculator:          Location Tracking Calc.
                                                              (line   6)
* location, textual <1>:                 Locations.           (line   6)
* location, textual:                     Tracking Locations.  (line   6)
* location_type:                         C++ Parser Interface.
                                                              (line  16)
* lookahead correction:                  LAC.                 (line   6)
* lookahead token:                       Lookahead.           (line   6)
* LR:                                    Mysterious Conflicts.
                                                              (line  33)
* LR grammars:                           Language and Grammar.
                                                              (line  22)
* ltcalc:                                Location Tracking Calc.
                                                              (line   6)
* main function in simple example:       Rpcalc Main.         (line   6)
* memory exhaustion:                     Memory Management.   (line   6)
* memory management:                     Memory Management.   (line   6)
* mfcalc:                                Multi-function Calc. (line   6)
* mid-rule actions <1>:                  Mid-Rule Actions.    (line   6)
* mid-rule actions:                      Destructor Decl.     (line  88)
* multi-function calculator:             Multi-function Calc. (line   6)
* multicharacter literal:                Symbols.             (line  59)
* mutual recursion:                      Recursion.           (line  34)
* Mysterious Conflict:                   LR Table Construction.
                                                              (line   6)
* Mysterious Conflicts:                  Mysterious Conflicts.
                                                              (line   6)
* named references:                      Named References.    (line   6)
* NLS:                                   Internationalization.
                                                              (line   6)
* nondeterministic parsing <1>:          Generalized LR Parsing.
                                                              (line   6)
* nondeterministic parsing:              Language and Grammar.
                                                              (line  34)
* nonterminal symbol:                    Symbols.             (line   6)
* nonterminal, useless:                  Understanding.       (line  49)
* operator precedence:                   Precedence.          (line   6)
* operator precedence, declaring:        Precedence Decl.     (line   6)
* operator!= on location:                C++ location.        (line  39)
* operator!= on position:                C++ position.        (line  42)
* operator+ on location:                 C++ location.        (line  30)
* operator+ on position:                 C++ position.        (line  36)
* operator+= on location:                C++ location.        (line  32)
* operator+= on position:                C++ position.        (line  35)
* operator- on position:                 C++ position.        (line  38)
* operator-= on position:                C++ position.        (line  37)
* operator<< <1>:                        C++ position.        (line  46)
* operator<<:                            C++ location.        (line  44)
* operator== on location:                C++ location.        (line  38)
* operator== on position:                C++ position.        (line  41)
* options for invoking Bison:            Invocation.          (line   6)
* overflow of parser stack:              Memory Management.   (line   6)
* parse error:                           Error Reporting.     (line   6)
* parse on parser:                       C++ Parser Interface.
                                                              (line  30)
* parse on YYParser:                     Java Parser Interface.
                                                              (line  54)
* parser:                                Bison Parser.        (line   6)
* parser on parser:                      C++ Parser Interface.
                                                              (line  26)
* parser stack:                          Algorithm.           (line   6)
* parser stack overflow:                 Memory Management.   (line   6)
* parser state:                          Parser States.       (line   6)
* pointed rule:                          Understanding.       (line 103)
* polish notation calculator:            RPN Calc.            (line   6)
* position on position:                  C++ position.        (line   8)
* precedence declarations:               Precedence Decl.     (line   6)
* precedence of operators:               Precedence.          (line   6)
* precedence, context-dependent:         Contextual Precedence.
                                                              (line   6)
* precedence, unary operator:            Contextual Precedence.
                                                              (line   6)
* preventing warnings about conflicts:   Expect Decl.         (line   6)
* printing semantic values:              Printer Decl.        (line   6)
* Prologue <1>:                          Prologue.            (line   6)
* Prologue:                              %code Summary.       (line   6)
* Prologue Alternatives:                 Prologue Alternatives.
                                                              (line   6)
* pure parser:                           Pure Decl.           (line   6)
* push parser:                           Push Decl.           (line   6)
* questions:                             FAQ.                 (line   6)
* recovering:                            Java Action Features.
                                                              (line  55)
* recovering on YYParser:                Java Parser Interface.
                                                              (line  58)
* recovery from errors:                  Error Recovery.      (line   6)
* recursive rule:                        Recursion.           (line   6)
* reduce/reduce conflict:                Reduce/Reduce.       (line   6)
* reduce/reduce conflicts <1>:           Merging GLR Parses.  (line   6)
* reduce/reduce conflicts <2>:           GLR Parsers.         (line   6)
* reduce/reduce conflicts:               Simple GLR Parsers.  (line   6)
* reduction:                             Algorithm.           (line   6)
* reentrant parser:                      Pure Decl.           (line   6)
* requiring a version of Bison:          Require Decl.        (line   6)
* reverse polish notation:               RPN Calc.            (line   6)
* right recursion:                       Recursion.           (line  17)
* rpcalc:                                RPN Calc.            (line   6)
* rule syntax:                           Rules.               (line   6)
* rule, pointed:                         Understanding.       (line 103)
* rule, useless:                         Understanding.       (line  49)
* rules section for grammar:             Grammar Rules.       (line   6)
* running Bison (introduction):          Rpcalc Generate.     (line   6)
* semantic actions:                      Semantic Actions.    (line   6)
* semantic value:                        Semantic Values.     (line   6)
* semantic value type:                   Value Type.          (line   6)
* semantic_type:                         C++ Parser Interface.
                                                              (line  15)
* set_debug_level on parser:             C++ Parser Interface.
                                                              (line  39)
* set_debug_stream on parser:            C++ Parser Interface.
                                                              (line  34)
* setDebugLevel on YYParser:             Java Parser Interface.
                                                              (line  68)
* setDebugStream on YYParser:            Java Parser Interface.
                                                              (line  63)
* shift/reduce conflicts <1>:            Shift/Reduce.        (line   6)
* shift/reduce conflicts <2>:            Simple GLR Parsers.  (line   6)
* shift/reduce conflicts:                GLR Parsers.         (line   6)
* shifting:                              Algorithm.           (line   6)
* simple examples:                       Examples.            (line   6)
* single-character literal:              Symbols.             (line  37)
* stack overflow:                        Memory Management.   (line   6)
* stack, parser:                         Algorithm.           (line   6)
* stages in using Bison:                 Stages.              (line   6)
* start symbol:                          Language and Grammar.
                                                              (line  97)
* start symbol, declaring:               Start Decl.          (line   6)
* state (of parser):                     Parser States.       (line   6)
* step on location:                      C++ location.        (line  35)
* string token:                          Symbols.             (line  59)
* summary, action features:              Action Features.     (line   6)
* summary, Bison declaration:            Decl Summary.        (line   6)
* suppressing conflict warnings:         Expect Decl.         (line   6)
* symbol:                                Symbols.             (line   6)
* symbol table example:                  Mfcalc Symbol Table. (line   6)
* symbols (abstract):                    Language and Grammar.
                                                              (line  48)
* symbols in Bison, table of:            Table of Symbols.    (line   6)
* syntactic grouping:                    Language and Grammar.
                                                              (line  48)
* syntax error:                          Error Reporting.     (line   6)
* syntax of grammar rules:               Rules.               (line   6)
* terminal symbol:                       Symbols.             (line   6)
* textual location <1>:                  Tracking Locations.  (line   6)
* textual location:                      Locations.           (line   6)
* token <1>:                             Language and Grammar.
                                                              (line  48)
* token:                                 C++ Parser Interface.
                                                              (line  19)
* token type:                            Symbols.             (line   6)
* token type names, declaring:           Token Decl.          (line   6)
* token, useless:                        Understanding.       (line  49)
* toString on Location:                  Java Location Values.
                                                              (line  32)
* tracing the parser:                    Tracing.             (line   6)
* uint:                                  C++ Location Values. (line  12)
* unary operator precedence:             Contextual Precedence.
                                                              (line   6)
* unreachable states:                    Unreachable States.  (line   6)
* useless nonterminal:                   Understanding.       (line  49)
* useless rule:                          Understanding.       (line  49)
* useless token:                         Understanding.       (line  49)
* using Bison:                           Stages.              (line   6)
* value type, semantic:                  Value Type.          (line   6)
* value types, declaring:                Union Decl.          (line   6)
* value types, nonterminals, declaring:  Type Decl.           (line   6)
* value, semantic:                       Semantic Values.     (line   6)
* version requirement:                   Require Decl.        (line   6)
* warnings, preventing:                  Expect Decl.         (line   6)
* writing a lexical analyzer:            Rpcalc Lexer.        (line   6)
* YYABORT <1>:                           Java Action Features.
                                                              (line  43)
* YYABORT <2>:                           Parser Function.     (line  29)
* YYABORT <3>:                           Table of Symbols.    (line 249)
* YYABORT:                               Action Features.     (line  28)
* YYACCEPT <1>:                          Action Features.     (line  32)
* YYACCEPT <2>:                          Java Action Features.
                                                              (line  47)
* YYACCEPT <3>:                          Table of Symbols.    (line 258)
* YYACCEPT:                              Parser Function.     (line  26)
* YYBACKUP <1>:                          Table of Symbols.    (line 266)
* YYBACKUP:                              Action Features.     (line  36)
* yychar <1>:                            Table of Symbols.    (line 270)
* yychar <2>:                            Lookahead.           (line  49)
* yychar <3>:                            Action Features.     (line  69)
* yychar:                                GLR Semantic Actions.
                                                              (line  10)
* yyclearin <1>:                         Table of Symbols.    (line 276)
* yyclearin <2>:                         Error Recovery.      (line  99)
* yyclearin <3>:                         GLR Semantic Actions.
                                                              (line  18)
* yyclearin:                             Action Features.     (line  76)
* YYDEBUG:                               Table of Symbols.    (line 280)
* yydebug <1>:                           Table of Symbols.    (line 284)
* yydebug:                               Tracing.             (line   6)
* YYDEBUG:                               Enabling Traces.     (line   9)
* YYEMPTY:                               Action Features.     (line  49)
* YYENABLE_NLS:                          Internationalization.
                                                              (line  27)
* YYEOF:                                 Action Features.     (line  52)
* yyerrok <1>:                           Error Recovery.      (line  94)
* yyerrok <2>:                           Action Features.     (line  81)
* yyerrok:                               Table of Symbols.    (line 289)
* yyerror:                               Java Action Features.
                                                              (line  61)
* YYERROR:                               Java Action Features.
                                                              (line  51)
* yyerror:                               Java Action Features.
                                                              (line  62)
* YYERROR:                               Table of Symbols.    (line 293)
* yyerror:                               Table of Symbols.    (line 304)
* YYERROR <1>:                           GLR Semantic Actions.
                                                              (line  28)
* YYERROR:                               Action Features.     (line  56)
* yyerror:                               Error Reporting.     (line   6)
* yyerror on Lexer:                      Java Scanner Interface.
                                                              (line  25)
* YYERROR_VERBOSE:                       Table of Symbols.    (line 308)
* YYFPRINTF <1>:                         Table of Symbols.    (line 316)
* YYFPRINTF:                             Enabling Traces.     (line  36)
* YYINITDEPTH <1>:                       Memory Management.   (line  32)
* YYINITDEPTH:                           Table of Symbols.    (line 319)
* yylex <1>:                             Table of Symbols.    (line 323)
* yylex:                                 Lexical.             (line   6)
* yylex on Lexer:                        Java Scanner Interface.
                                                              (line  30)
* yylex on parser:                       C++ Scanner Interface.
                                                              (line  12)
* YYLEX_PARAM:                           Table of Symbols.    (line 328)
* yylloc <1>:                            GLR Semantic Actions.
                                                              (line  10)
* yylloc <2>:                            Table of Symbols.    (line 334)
* yylloc <3>:                            Action Features.     (line  86)
* yylloc <4>:                            Actions and Locations.
                                                              (line  67)
* yylloc <5>:                            Token Locations.     (line   6)
* yylloc:                                Lookahead.           (line  49)
* YYLLOC_DEFAULT:                        Location Default Action.
                                                              (line   6)
* YYLTYPE <1>:                           Table of Symbols.    (line 344)
* YYLTYPE:                               Token Locations.     (line  19)
* yylval <1>:                            Lookahead.           (line  49)
* yylval <2>:                            Token Values.        (line   6)
* yylval <3>:                            GLR Semantic Actions.
                                                              (line  10)
* yylval <4>:                            Actions.             (line  87)
* yylval <5>:                            Table of Symbols.    (line 348)
* yylval:                                Action Features.     (line  92)
* YYMAXDEPTH <1>:                        Table of Symbols.    (line 356)
* YYMAXDEPTH:                            Memory Management.   (line  14)
* yynerrs <1>:                           Error Reporting.     (line  94)
* yynerrs:                               Table of Symbols.    (line 360)
* yyoutput:                              Printer Decl.        (line  16)
* yyparse <1>:                           Parser Function.     (line   6)
* yyparse <2>:                           Table of Symbols.    (line 366)
* yyparse:                               Parser Function.     (line  13)
* YYPARSE_PARAM:                         Table of Symbols.    (line 404)
* YYParser on YYParser:                  Java Parser Interface.
                                                              (line  46)
* YYPRINT <1>:                           Table of Symbols.    (line 370)
* YYPRINT:                               The YYPRINT Macro.   (line  11)
* yypstate_delete <1>:                   Parser Delete Function.
                                                              (line  15)
* yypstate_delete:                       Table of Symbols.    (line 375)
* yypstate_new <1>:                      Table of Symbols.    (line 383)
* yypstate_new:                          Parser Create Function.
                                                              (line   6)
* yypull_parse <1>:                      Table of Symbols.    (line 390)
* yypull_parse:                          Pull Parser Function.
                                                              (line  14)
* yypush_parse <1>:                      Push Parser Function.
                                                              (line  15)
* yypush_parse <2>:                      Table of Symbols.    (line 397)
* yypush_parse:                          Push Parser Function.
                                                              (line   6)
* YYRECOVERING <1>:                      Table of Symbols.    (line 410)
* YYRECOVERING <2>:                      Error Recovery.      (line 111)
* YYRECOVERING:                          Action Features.     (line  64)
* YYSTACK_USE_ALLOCA:                    Table of Symbols.    (line 415)
* YYSTYPE:                               Table of Symbols.    (line 431)
* | <1>:                                 Table of Symbols.    (line  59)
* |:                                     Rules.               (line  48)