Add native Windows binary for bison.

bison/src/bison/2.4.1/bison-2.4.1-src/doc/bison.info

+This is ../../bison-2.4.1-src/doc/bison.info, produced by makeinfo
+version 4.8 from ../../bison-2.4.1-src/doc/bison.texinfo.
+
+   This manual (19 November 2008) is for GNU Bison (version 2.4.1), the
+GNU parser generator.
+
+   Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1995, 1998, 1999,
+2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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
+
+
+File: bison.info,  Node: Top,  Next: Introduction,  Up: (dir)
+
+Bison
+*****
+
+This manual (19 November 2008) is for GNU Bison (version 2.4.1), the
+GNU parser generator.
+
+   Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1995, 1998, 1999,
+2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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."
+
+* Menu:
+
+* Introduction::
+* Conditions::
+* Copying::             The GNU General Public License says
+                          how you can copy and share Bison.
+
+Tutorial sections:
+* Concepts::            Basic concepts for understanding Bison.
+* Examples::            Three simple explained examples of using Bison.
+
+Reference sections:
+* Grammar File::        Writing Bison declarations and rules.
+* Interface::           C-language interface to the parser function `yyparse'.
+* Algorithm::           How the Bison parser works at run-time.
+* Error Recovery::      Writing rules for error recovery.
+* Context Dependency::  What to do if your language syntax is too
+                          messy for Bison to handle straightforwardly.
+* Debugging::           Understanding or debugging Bison parsers.
+* Invocation::          How to run Bison (to produce the parser source file).
+* Other Languages::     Creating C++ and Java parsers.
+* FAQ::                 Frequently Asked Questions
+* Table of Symbols::    All the keywords of the Bison language are explained.
+* Glossary::            Basic concepts are explained.
+* Copying This Manual:: License for copying this manual.
+* Index::               Cross-references to the text.
+
+ --- The Detailed Node Listing ---
+
+The Concepts of Bison
+
+* Language and Grammar:: Languages and context-free grammars,
+                           as mathematical ideas.
+* Grammar in Bison::     How we represent grammars for Bison's sake.
+* Semantic Values::      Each token or syntactic grouping can have
+                           a semantic value (the value of an integer,
+                           the name of an identifier, etc.).
+* Semantic Actions::     Each rule can have an action containing C code.
+* GLR Parsers::          Writing parsers for general context-free languages.
+* Locations Overview::   Tracking Locations.
+* Bison Parser::         What are Bison's input and output,
+                           how is the output used?
+* Stages::               Stages in writing and running Bison grammars.
+* Grammar Layout::       Overall structure of a Bison grammar file.
+
+Writing GLR Parsers
+
+* Simple GLR Parsers::     Using GLR parsers on unambiguous grammars.
+* Merging GLR Parses::     Using GLR parsers to resolve ambiguities.
+* GLR Semantic Actions::   Deferred semantic actions have special concerns.
+* Compiler Requirements::  GLR parsers require a modern C compiler.
+
+Examples
+
+* RPN Calc::               Reverse polish notation calculator;
+                             a first example with no operator precedence.
+* Infix Calc::             Infix (algebraic) notation calculator.
+                             Operator precedence is introduced.
+* Simple Error Recovery::  Continuing after syntax errors.
+* Location Tracking Calc:: Demonstrating the use of @N and @$.
+* Multi-function Calc::    Calculator with memory and trig functions.
+                             It uses multiple data-types for semantic values.
+* Exercises::              Ideas for improving the multi-function calculator.
+
+Reverse Polish Notation Calculator
+
+* Rpcalc Declarations::    Prologue (declarations) for rpcalc.
+* Rpcalc Rules::           Grammar Rules for rpcalc, with explanation.
+* Rpcalc Lexer::           The lexical analyzer.
+* Rpcalc Main::            The controlling function.
+* Rpcalc Error::           The error reporting function.
+* Rpcalc Generate::        Running Bison on the grammar file.
+* Rpcalc Compile::         Run the C compiler on the output code.
+
+Grammar Rules for `rpcalc'
+
+* Rpcalc Input::
+* Rpcalc Line::
+* Rpcalc Expr::
+
+Location Tracking Calculator: `ltcalc'
+
+* Ltcalc Declarations::    Bison and C declarations for ltcalc.
+* Ltcalc Rules::           Grammar rules for ltcalc, with explanations.
+* Ltcalc Lexer::           The lexical analyzer.
+
+Multi-Function Calculator: `mfcalc'
+
+* Mfcalc Declarations::    Bison declarations for multi-function calculator.
+* Mfcalc Rules::           Grammar rules for the calculator.
+* Mfcalc Symbol Table::    Symbol table management subroutines.
+
+Bison Grammar Files
+
+* Grammar Outline::   Overall layout of the grammar file.
+* Symbols::           Terminal and nonterminal symbols.
+* Rules::             How to write grammar rules.
+* Recursion::         Writing recursive rules.
+* Semantics::         Semantic values and actions.
+* Locations::         Locations and actions.
+* Declarations::      All kinds of Bison declarations are described here.
+* Multiple Parsers::  Putting more than one Bison parser in one program.
+
+Outline of a Bison Grammar
+
+* Prologue::              Syntax and usage of the prologue.
+* Prologue Alternatives:: Syntax and usage of alternatives to the prologue.
+* Bison Declarations::    Syntax and usage of the Bison declarations section.
+* Grammar Rules::         Syntax and usage of the grammar rules section.
+* Epilogue::              Syntax and usage of the epilogue.
+
+Defining Language Semantics
+
+* Value Type::        Specifying one data type for all semantic values.
+* Multiple Types::    Specifying several alternative data types.
+* Actions::           An action is the semantic definition of a grammar rule.
+* Action Types::      Specifying data types for actions to operate on.
+* Mid-Rule Actions::  Most actions go at the end of a rule.
+                      This says when, why and how to use the exceptional
+                        action in the middle of a rule.
+
+Tracking Locations
+
+* Location Type::               Specifying a data type for locations.
+* Actions and Locations::       Using locations in actions.
+* Location Default Action::     Defining a general way to compute locations.
+
+Bison Declarations
+
+* Require Decl::      Requiring a Bison version.
+* Token Decl::        Declaring terminal symbols.
+* Precedence Decl::   Declaring terminals with precedence and associativity.
+* Union Decl::        Declaring the set of all semantic value types.
+* Type Decl::         Declaring the choice of type for a nonterminal symbol.
+* Initial Action Decl::  Code run before parsing starts.
+* Destructor Decl::   Declaring how symbols are freed.
+* Expect Decl::       Suppressing warnings about parsing conflicts.
+* Start Decl::        Specifying the start symbol.
+* Pure Decl::         Requesting a reentrant parser.
+* Push Decl::         Requesting a push parser.
+* Decl Summary::      Table of all Bison declarations.
+
+Parser C-Language Interface
+
+* Parser Function::         How to call `yyparse' and what it returns.
+* Push Parser Function::    How to call `yypush_parse' and what it returns.
+* Pull Parser Function::    How to call `yypull_parse' and what it returns.
+* Parser Create Function::  How to call `yypstate_new' and what it returns.
+* Parser Delete Function::  How to call `yypstate_delete' and what it returns.
+* Lexical::                 You must supply a function `yylex'
+                              which reads tokens.
+* Error Reporting::         You must supply a function `yyerror'.
+* Action Features::         Special features for use in actions.
+* Internationalization::    How to let the parser speak in the user's
+                              native language.
+
+The Lexical Analyzer Function `yylex'
+
+* Calling Convention::  How `yyparse' calls `yylex'.
+* Token Values::        How `yylex' must return the semantic value
+                          of the token it has read.
+* Token Locations::     How `yylex' must return the text location
+                          (line number, etc.) of the token, if the
+                          actions want that.
+* Pure Calling::        How the calling convention differs in a pure parser
+                          (*note A Pure (Reentrant) Parser: Pure Decl.).
+
+The Bison Parser Algorithm
+
+* Lookahead::         Parser looks one token ahead when deciding what to do.
+* Shift/Reduce::      Conflicts: when either shifting or reduction is valid.
+* Precedence::        Operator precedence works by resolving conflicts.
+* Contextual Precedence::  When an operator's precedence depends on context.
+* Parser States::     The parser is a finite-state-machine with stack.
+* Reduce/Reduce::     When two rules are applicable in the same situation.
+* Mystery Conflicts:: Reduce/reduce conflicts that look unjustified.
+* Generalized LR Parsing::  Parsing arbitrary context-free grammars.
+* Memory Management:: What happens when memory is exhausted.  How to avoid it.
+
+Operator Precedence
+
+* Why Precedence::    An example showing why precedence is needed.
+* Using Precedence::  How to specify precedence in Bison grammars.
+* Precedence Examples::  How these features are used in the previous example.
+* How Precedence::    How they work.
+
+Handling Context Dependencies
+
+* 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.
+
+Debugging Your Parser
+
+* Understanding::     Understanding the structure of your parser.
+* Tracing::           Tracing the execution of your parser.
+
+Invoking Bison
+
+* 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'.
+
+Parsers Written In Other Languages
+
+* C++ Parsers::                 The interface to generate C++ parser classes
+* Java Parsers::                The interface to generate Java parser classes
+
+C++ Parsers
+
+* 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
+
+A Complete C++ Example
+
+* 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
+
+Java Parsers
+
+* 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
+
+Frequently Asked Questions
+
+* 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
+
+Copying This Manual
+
+* Copying This Manual::         License for copying this manual.
+
+
+File: bison.info,  Node: Introduction,  Next: Conditions,  Prev: Top,  Up: Top
+
+Introduction
+************
+
+"Bison" is a general-purpose parser generator that converts an
+annotated context-free grammar into an LALR(1) or GLR parser for that
+grammar.  Once you are proficient with Bison, you can use it to develop
+a wide range of language parsers, from those used in simple desk
+calculators to complex programming languages.
+
+   Bison is upward compatible with Yacc: all properly-written Yacc
+grammars ought to work with Bison with no change.  Anyone familiar with
+Yacc should be able to use Bison with little trouble.  You need to be
+fluent in C or C++ programming in order to use Bison or to understand
+this manual.
+
+   We begin with tutorial chapters that explain the basic concepts of
+using Bison and show three explained examples, each building on the
+last.  If you don't know Bison or Yacc, start by reading these
+chapters.  Reference chapters follow which describe specific aspects of
+Bison in detail.
+
+   Bison was written primarily by Robert Corbett; Richard Stallman made
+it Yacc-compatible.  Wilfred Hansen of Carnegie Mellon University added
+multi-character string literals and other features.
+
+   This edition corresponds to version 2.4.1 of Bison.
+
+
+File: bison.info,  Node: Conditions,  Next: Copying,  Prev: Introduction,  Up: Top
+
+Conditions for Using Bison
+**************************
+
+The distribution terms for Bison-generated parsers permit using the
+parsers in nonfree programs.  Before Bison version 2.2, these extra
+permissions applied only when Bison was generating LALR(1) parsers in
+C.  And before Bison version 1.24, Bison-generated parsers could be
+used only in programs that were free software.
+
+   The other GNU programming tools, such as the GNU C compiler, have
+never had such a requirement.  They could always be used for nonfree
+software.  The reason Bison was different was not due to a special
+policy decision; it resulted from applying the usual General Public
+License to all of the Bison source code.
+
+   The output of the Bison utility--the Bison parser file--contains a
+verbatim copy of a sizable piece of Bison, which is the code for the
+parser's implementation.  (The actions from your grammar are inserted
+into this implementation at one point, but most of the rest of the
+implementation is not changed.)  When we applied the GPL terms to the
+skeleton code for the parser's implementation, the effect was to
+restrict the use of Bison output to free software.
+
+   We didn't change the terms because of sympathy for people who want to
+make software proprietary.  *Software should be free.*  But we
+concluded that limiting Bison's use to free software was doing little to
+encourage people to make other software free.  So we decided to make the
+practical conditions for using Bison match the practical conditions for
+using the other GNU tools.
+
+   This exception applies when Bison is generating code for a parser.
+You can tell whether the exception applies to a Bison output file by
+inspecting the file for text beginning with "As a special
+exception...".  The text spells out the exact terms of the exception.
+
+
+File: bison.info,  Node: Copying,  Next: Concepts,  Prev: Conditions,  Up: Top
+
+GNU GENERAL PUBLIC LICENSE
+**************************
+
+                        Version 3, 29 June 2007
+
+     Copyright (C) 2007 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.
+
+Preamble
+========
+
+The GNU General Public License is a free, copyleft license for software
+and other kinds of works.
+
+   The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains
+free software for all its users.  We, the Free Software Foundation, use
+the GNU General Public License for most of our software; it applies
+also to any other work released this way by its authors.  You can apply
+it to your programs, too.
+
+   When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+   To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you
+have certain responsibilities if you distribute copies of the software,
+or if you modify it: responsibilities to respect the freedom of others.
+
+   For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+   Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+   For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+   Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the
+manufacturer can do so.  This is fundamentally incompatible with the
+aim of protecting users' freedom to change the software.  The
+systematic pattern of such abuse occurs in the area of products for
+individuals to use, which is precisely where it is most unacceptable.
+Therefore, we have designed this version of the GPL to prohibit the
+practice for those products.  If such problems arise substantially in
+other domains, we stand ready to extend this provision to those domains
+in future versions of the GPL, as needed to protect the freedom of
+users.
+
+   Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+   The precise terms and conditions for copying, distribution and
+modification follow.
+
+TERMS AND CONDITIONS
+====================
+
+  0. Definitions.
+
+     "This License" refers to version 3 of the GNU General Public
+     License.
+
+     "Copyright" also means copyright-like laws that apply to other
+     kinds of works, such as semiconductor masks.
+
+     "The Program" refers to any copyrightable work licensed under this
+     License.  Each licensee is addressed as "you".  "Licensees" and
+     "recipients" may be individuals or organizations.
+
+     To "modify" a work means to copy from or adapt all or part of the
+     work in a fashion requiring copyright permission, other than the
+     making of an exact copy.  The resulting work is called a "modified
+     version" of the earlier work or a work "based on" the earlier work.
+
+     A "covered work" means either the unmodified Program or a work
+     based on the Program.
+
+     To "propagate" a work means to do anything with it that, without
+     permission, would make you directly or secondarily liable for
+     infringement under applicable copyright law, except executing it
+     on a computer or modifying a private copy.  Propagation includes
+     copying, distribution (with or without modification), making
+     available to the public, and in some countries other activities as
+     well.
+
+     To "convey" a work means any kind of propagation that enables other
+     parties to make or receive copies.  Mere interaction with a user
+     through a computer network, with no transfer of a copy, is not
+     conveying.
+
+     An interactive user interface displays "Appropriate Legal Notices"
+     to the extent that it includes a convenient and prominently visible
+     feature that (1) displays an appropriate copyright notice, and (2)
+     tells the user that there is no warranty for the work (except to
+     the extent that warranties are provided), that licensees may
+     convey the work under this License, and how to view a copy of this
+     License.  If the interface presents a list of user commands or
+     options, such as a menu, a prominent item in the list meets this
+     criterion.
+
+  1. Source Code.
+
+     The "source code" for a work means the preferred form of the work
+     for making modifications to it.  "Object code" means any
+     non-source form of a work.
+
+     A "Standard Interface" means an interface that either is an
+     official standard defined by a recognized standards body, or, in
+     the case of interfaces specified for a particular programming
+     language, one that is widely used among developers working in that
+     language.
+
+     The "System Libraries" of an executable work include anything,
+     other than the work as a whole, that (a) is included in the normal
+     form of packaging a Major Component, but which is not part of that
+     Major Component, and (b) serves only to enable use of the work
+     with that Major Component, or to implement a Standard Interface
+     for which an implementation is available to the public in source
+     code form.  A "Major Component", in this context, means a major
+     essential component (kernel, window system, and so on) of the
+     specific operating system (if any) on which the executable work
+     runs, or a compiler used to produce the work, or an object code
+     interpreter used to run it.
+
+     The "Corresponding Source" for a work in object code form means all
+     the source code needed to generate, install, and (for an executable
+     work) run the object code and to modify the work, including
+     scripts to control those activities.  However, it does not include
+     the work's System Libraries, or general-purpose tools or generally
+     available free programs which are used unmodified in performing
+     those activities but which are not part of the work.  For example,
+     Corresponding Source includes interface definition files
+     associated with source files for the work, and the source code for
+     shared libraries and dynamically linked subprograms that the work
+     is specifically designed to require, such as by intimate data
+     communication or control flow between those subprograms and other
+     parts of the work.
+
+     The Corresponding Source need not include anything that users can
+     regenerate automatically from other parts of the Corresponding
+     Source.
+
+     The Corresponding Source for a work in source code form is that
+     same work.
+
+  2. Basic Permissions.
+
+     All rights granted under this License are granted for the term of
+     copyright on the Program, and are irrevocable provided the stated
+     conditions are met.  This License explicitly affirms your unlimited
+     permission to run the unmodified Program.  The output from running
+     a covered work is covered by this License only if the output,
+     given its content, constitutes a covered work.  This License
+     acknowledges your rights of fair use or other equivalent, as
+     provided by copyright law.
+
+     You may make, run and propagate covered works that you do not
+     convey, without conditions so long as your license otherwise
+     remains in force.  You may convey covered works to others for the
+     sole purpose of having them make modifications exclusively for
+     you, or provide you with facilities for running those works,
+     provided that you comply with the terms of this License in
+     conveying all material for which you do not control copyright.
+     Those thus making or running the covered works for you must do so
+     exclusively on your behalf, under your direction and control, on
+     terms that prohibit them from making any copies of your
+     copyrighted material outside their relationship with you.
+
+     Conveying under any other circumstances is permitted solely under
+     the conditions stated below.  Sublicensing is not allowed; section
+     10 makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+     No covered work shall be deemed part of an effective technological
+     measure under any applicable law fulfilling obligations under
+     article 11 of the WIPO copyright treaty adopted on 20 December
+     1996, or similar laws prohibiting or restricting circumvention of
+     such measures.
+
+     When you convey a covered work, you waive any legal power to forbid
+     circumvention of technological measures to the extent such
+     circumvention is effected by exercising rights under this License
+     with respect to the covered work, and you disclaim any intention
+     to limit operation or modification of the work as a means of
+     enforcing, against the work's users, your or third parties' legal
+     rights to forbid circumvention of technological measures.
+
+  4. Conveying Verbatim Copies.
+
+     You may convey verbatim copies of the Program's source code as you
+     receive it, in any medium, provided that you conspicuously and
+     appropriately publish on each copy an appropriate copyright notice;
+     keep intact all notices stating that this License and any
+     non-permissive terms added in accord with section 7 apply to the
+     code; keep intact all notices of the absence of any warranty; and
+     give all recipients a copy of this License along with the Program.
+
+     You may charge any price or no price for each copy that you convey,
+     and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+     You may convey a work based on the Program, or the modifications to
+     produce it from the Program, in the form of source code under the
+     terms of section 4, provided that you also meet all of these
+     conditions:
+
+       a. The work must carry prominent notices stating that you
+          modified it, and giving a relevant date.
+
+       b. The work must carry prominent notices stating that it is
+          released under this License and any conditions added under
+          section 7.  This requirement modifies the requirement in
+          section 4 to "keep intact all notices".
+
+       c. You must license the entire work, as a whole, under this
+          License to anyone who comes into possession of a copy.  This
+          License will therefore apply, along with any applicable
+          section 7 additional terms, to the whole of the work, and all
+          its parts, regardless of how they are packaged.  This License
+          gives no permission to license the work in any other way, but
+          it does not invalidate such permission if you have separately
+          received it.
+
+       d. If the work has interactive user interfaces, each must display
+          Appropriate Legal Notices; however, if the Program has
+          interactive interfaces that do not display Appropriate Legal
+          Notices, your work need not make them do so.
+
+     A compilation of a covered work with other separate and independent
+     works, which are not by their nature extensions of the covered
+     work, and which are not combined with it such as to form a larger
+     program, in or on a volume of a storage or distribution medium, is
+     called an "aggregate" if the compilation and its resulting
+     copyright are not used to limit the access or legal rights of the
+     compilation's users beyond what the individual works permit.
+     Inclusion of a covered work in an aggregate does not cause this
+     License to apply to the other parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+     You may convey a covered work in object code form under the terms
+     of sections 4 and 5, provided that you also convey the
+     machine-readable Corresponding Source under the terms of this
+     License, in one of these ways:
+
+       a. Convey the object code in, or embodied in, a physical product
+          (including a physical distribution medium), accompanied by the
+          Corresponding Source fixed on a durable physical medium
+          customarily used for software interchange.
+
+       b. Convey the object code in, or embodied in, a physical product
+          (including a physical distribution medium), accompanied by a
+          written offer, valid for at least three years and valid for
+          as long as you offer spare parts or customer support for that
+          product model, to give anyone who possesses the object code
+          either (1) a copy of the Corresponding Source for all the
+          software in the product that is covered by this License, on a
+          durable physical medium customarily used for software
+          interchange, for a price no more than your reasonable cost of
+          physically performing this conveying of source, or (2) access
+          to copy the Corresponding Source from a network server at no
+          charge.
+
+       c. Convey individual copies of the object code with a copy of
+          the written offer to provide the Corresponding Source.  This
+          alternative is allowed only occasionally and noncommercially,
+          and only if you received the object code with such an offer,
+          in accord with subsection 6b.
+
+       d. Convey the object code by offering access from a designated
+          place (gratis or for a charge), and offer equivalent access
+          to the Corresponding Source in the same way through the same
+          place at no further charge.  You need not require recipients
+          to copy the Corresponding Source along with the object code.
+          If the place to copy the object code is a network server, the
+          Corresponding Source may be on a different server (operated
+          by you or a third party) that supports equivalent copying
+          facilities, provided you maintain clear directions next to
+          the object code saying where to find the Corresponding Source.
+          Regardless of what server hosts the Corresponding Source, you
+          remain obligated to ensure that it is available for as long
+          as needed to satisfy these requirements.
+
+       e. Convey the object code using peer-to-peer transmission,
+          provided you inform other peers where the object code and
+          Corresponding Source of the work are being offered to the
+          general public at no charge under subsection 6d.
+
+
+     A separable portion of the object code, whose source code is
+     excluded from the Corresponding Source as a System Library, need
+     not be included in conveying the object code work.
+
+     A "User Product" is either (1) a "consumer product", which means
+     any tangible personal property which is normally used for personal,
+     family, or household purposes, or (2) anything designed or sold for
+     incorporation into a dwelling.  In determining whether a product
+     is a consumer product, doubtful cases shall be resolved in favor of
+     coverage.  For a particular product received by a particular user,
+     "normally used" refers to a typical or common use of that class of
+     product, regardless of the status of the particular user or of the
+     way in which the particular user actually uses, or expects or is
+     expected to use, the product.  A product is a consumer product
+     regardless of whether the product has substantial commercial,
+     industrial or non-consumer uses, unless such uses represent the
+     only significant mode of use of the product.
+
+     "Installation Information" for a User Product means any methods,
+     procedures, authorization keys, or other information required to
+     install and execute modified versions of a covered work in that
+     User Product from a modified version of its Corresponding Source.
+     The information must suffice to ensure that the continued
+     functioning of the modified object code is in no case prevented or
+     interfered with solely because modification has been made.
+
+     If you convey an object code work under this section in, or with,
+     or specifically for use in, a User Product, and the conveying
+     occurs as part of a transaction in which the right of possession
+     and use of the User Product is transferred to the recipient in
+     perpetuity or for a fixed term (regardless of how the transaction
+     is characterized), the Corresponding Source conveyed under this
+     section must be accompanied by the Installation Information.  But
+     this requirement does not apply if neither you nor any third party
+     retains the ability to install modified object code on the User
+     Product (for example, the work has been installed in ROM).
+
+     The requirement to provide Installation Information does not
+     include a requirement to continue to provide support service,
+     warranty, or updates for a work that has been modified or
+     installed by the recipient, or for the User Product in which it
+     has been modified or installed.  Access to a network may be denied
+     when the modification itself materially and adversely affects the
+     operation of the network or violates the rules and protocols for
+     communication across the network.
+
+     Corresponding Source conveyed, and Installation Information
+     provided, in accord with this section must be in a format that is
+     publicly documented (and with an implementation available to the
+     public in source code form), and must require no special password
+     or key for unpacking, reading or copying.
+
+  7. Additional Terms.
+
+     "Additional permissions" are terms that supplement the terms of
+     this License by making exceptions from one or more of its
+     conditions.  Additional permissions that are applicable to the
+     entire Program shall be treated as though they were included in
+     this License, to the extent that they are valid under applicable
+     law.  If additional permissions apply only to part of the Program,
+     that part may be used separately under those permissions, but the
+     entire Program remains governed by this License without regard to
+     the additional permissions.
+
+     When you convey a copy of a covered work, you may at your option
+     remove any additional permissions from that copy, or from any part
+     of it.  (Additional permissions may be written to require their own
+     removal in certain cases when you modify the work.)  You may place
+     additional permissions on material, added by you to a covered work,
+     for which you have or can give appropriate copyright permission.
+
+     Notwithstanding any other provision of this License, for material
+     you add to a covered work, you may (if authorized by the copyright
+     holders of that material) supplement the terms of this License
+     with terms:
+
+       a. Disclaiming warranty or limiting liability differently from
+          the terms of sections 15 and 16 of this License; or
+
+       b. Requiring preservation of specified reasonable legal notices
+          or author attributions in that material or in the Appropriate
+          Legal Notices displayed by works containing it; or
+
+       c. Prohibiting misrepresentation of the origin of that material,
+          or requiring that modified versions of such material be
+          marked in reasonable ways as different from the original
+          version; or
+
+       d. Limiting the use for publicity purposes of names of licensors
+          or authors of the material; or
+
+       e. Declining to grant rights under trademark law for use of some
+          trade names, trademarks, or service marks; or
+
+       f. Requiring indemnification of licensors and authors of that
+          material by anyone who conveys the material (or modified
+          versions of it) with contractual assumptions of liability to
+          the recipient, for any liability that these contractual
+          assumptions directly impose on those licensors and authors.
+
+     All other non-permissive additional terms are considered "further
+     restrictions" within the meaning of section 10.  If the Program as
+     you received it, or any part of it, contains a notice stating that
+     it is governed by this License along with a term that is a further
+     restriction, you may remove that term.  If a license document
+     contains a further restriction but permits relicensing or
+     conveying under this License, you may add to a covered work
+     material governed by the terms of that license document, provided
+     that the further restriction does not survive such relicensing or
+     conveying.
+
+     If you add terms to a covered work in accord with this section, you
+     must place, in the relevant source files, a statement of the
+     additional terms that apply to those files, or a notice indicating
+     where to find the applicable terms.
+
+     Additional terms, permissive or non-permissive, may be stated in
+     the form of a separately written license, or stated as exceptions;
+     the above requirements apply either way.
+
+  8. Termination.
+
+     You may not propagate or modify a covered work except as expressly
+     provided under this License.  Any attempt otherwise to propagate or
+     modify it is void, and will automatically terminate your rights
+     under this License (including any patent licenses granted under
+     the third paragraph of section 11).
+
+     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, you do not qualify to receive new
+     licenses for the same material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+     You are not required to accept this License in order to receive or
+     run a copy of the Program.  Ancillary propagation of a covered work
+     occurring solely as a consequence of using peer-to-peer
+     transmission to receive a copy likewise does not require
+     acceptance.  However, nothing other than this License grants you
+     permission to propagate or modify any covered work.  These actions
+     infringe copyright if you do not accept this License.  Therefore,
+     by modifying or propagating a covered work, you indicate your
+     acceptance of this License to do so.
+
+ 10. Automatic Licensing of Downstream Recipients.
+
+     Each time you convey a covered work, the recipient automatically
+     receives a license from the original licensors, to run, modify and
+     propagate that work, subject to this License.  You are not
+     responsible for enforcing compliance by third parties with this
+     License.
+
+     An "entity transaction" is a transaction transferring control of an
+     organization, or substantially all assets of one, or subdividing an
+     organization, or merging organizations.  If propagation of a
+     covered work results from an entity transaction, each party to that
+     transaction who receives a copy of the work also receives whatever
+     licenses to the work the party's predecessor in interest had or
+     could give under the previous paragraph, plus a right to
+     possession of the Corresponding Source of the work from the
+     predecessor in interest, if the predecessor has it or can get it
+     with reasonable efforts.
+
+     You may not impose any further restrictions on the exercise of the
+     rights granted or affirmed under this License.  For example, you
+     may not impose a license fee, royalty, or other charge for
+     exercise of rights granted under this License, and you may not
+     initiate litigation (including a cross-claim or counterclaim in a
+     lawsuit) alleging that any patent claim is infringed by making,
+     using, selling, offering for sale, or importing the Program or any
+     portion of it.
+
+ 11. Patents.
+
+     A "contributor" is a copyright holder who authorizes use under this
+     License of the Program or a work on which the Program is based.
+     The work thus licensed is called the contributor's "contributor
+     version".
+
+     A contributor's "essential patent claims" are all patent claims
+     owned or controlled by the contributor, whether already acquired or
+     hereafter acquired, that would be infringed by some manner,
+     permitted by this License, of making, using, or selling its
+     contributor version, but do not include claims that would be
+     infringed only as a consequence of further modification of the
+     contributor version.  For purposes of this definition, "control"
+     includes the right to grant patent sublicenses in a manner
+     consistent with the requirements of this License.
+
+     Each contributor grants you a non-exclusive, worldwide,
+     royalty-free patent license under the contributor's essential
+     patent claims, to make, use, sell, offer for sale, import and
+     otherwise run, modify and propagate the contents of its
+     contributor version.
+
+     In the following three paragraphs, a "patent license" is any
+     express agreement or commitment, however denominated, not to
+     enforce a patent (such as an express permission to practice a
+     patent or covenant not to sue for patent infringement).  To
+     "grant" such a patent license to a party means to make such an
+     agreement or commitment not to enforce a patent against the party.
+
+     If you convey a covered work, knowingly relying on a patent
+     license, and the Corresponding Source of the work is not available
+     for anyone to copy, free of charge and under the terms of this
+     License, through a publicly available network server or other
+     readily accessible means, then you must either (1) cause the
+     Corresponding Source to be so available, or (2) arrange to deprive
+     yourself of the benefit of the patent license for this particular
+     work, or (3) arrange, in a manner consistent with the requirements
+     of this License, to extend the patent license to downstream
+     recipients.  "Knowingly relying" means you have actual knowledge
+     that, but for the patent license, your conveying the covered work
+     in a country, or your recipient's use of the covered work in a
+     country, would infringe one or more identifiable patents in that
+     country that you have reason to believe are valid.
+
+     If, pursuant to or in connection with a single transaction or
+     arrangement, you convey, or propagate by procuring conveyance of, a
+     covered work, and grant a patent license to some of the parties
+     receiving the covered work authorizing them to use, propagate,
+     modify or convey a specific copy of the covered work, then the
+     patent license you grant is automatically extended to all
+     recipients of the covered work and works based on it.
+
+     A patent license is "discriminatory" if it does not include within
+     the scope of its coverage, prohibits the exercise of, or is
+     conditioned on the non-exercise of one or more of the rights that
+     are specifically granted under this License.  You may not convey a
+     covered work if you are a party to an arrangement with a third
+     party that is in the business of distributing software, under
+     which you make payment to the third party based on the extent of
+     your activity of conveying the work, and under which the third
+     party grants, to any of the parties who would receive the covered
+     work from you, a discriminatory patent license (a) in connection
+     with copies of the covered work conveyed by you (or copies made
+     from those copies), or (b) primarily for and in connection with
+     specific products or compilations that contain the covered work,
+     unless you entered into that arrangement, or that patent license
+     was granted, prior to 28 March 2007.
+
+     Nothing in this License shall be construed as excluding or limiting
+     any implied license or other defenses to infringement that may
+     otherwise be available to you under applicable patent law.
+
+ 12. No Surrender of Others' Freedom.
+
+     If conditions are imposed on you (whether by court order,
+     agreement or otherwise) that contradict the conditions of this
+     License, they do not excuse you from the conditions of this
+     License.  If you cannot convey a covered work so as to satisfy
+     simultaneously your obligations under this License and any other
+     pertinent obligations, then as a consequence you may not convey it
+     at all.  For example, if you agree to terms that obligate you to
+     collect a royalty for further conveying from those to whom you
+     convey the Program, the only way you could satisfy both those
+     terms and this License would be to refrain entirely from conveying
+     the Program.
+
+ 13. Use with the GNU Affero General Public License.
+
+     Notwithstanding any other provision of this License, you have
+     permission to link or combine any covered work with a work licensed
+     under version 3 of the GNU Affero General Public License into a
+     single combined work, and to convey the resulting work.  The terms
+     of this License will continue to apply to the part which is the
+     covered work, but the special requirements of the GNU Affero
+     General Public License, section 13, concerning interaction through
+     a network will apply to the combination as such.
+
+ 14. Revised Versions of this License.
+
+     The Free Software Foundation may publish revised and/or new
+     versions of the GNU General Public 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.
+
+     Each version is given a distinguishing version number.  If the
+     Program specifies that a certain numbered version of the GNU
+     General Public License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that numbered version or of any later version published by the
+     Free Software Foundation.  If the Program does not specify a
+     version number of the GNU General Public License, you may choose
+     any version ever published by the Free Software Foundation.
+
+     If the Program specifies that a proxy can decide which future
+     versions of the GNU General Public License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Program.
+
+     Later license versions may give you additional or different
+     permissions.  However, no additional obligations are imposed on any
+     author or copyright holder as a result of your choosing to follow a
+     later version.
+
+ 15. Disclaimer of Warranty.
+
+     THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+     APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE
+     COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
+     WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
+     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE
+     RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
+     SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
+     NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+ 16. Limitation of Liability.
+
+     IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+     WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
+     AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
+     FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+     CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
+     THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
+     BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+     PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+     PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
+     THE POSSIBILITY OF SUCH DAMAGES.
+
+ 17. Interpretation of Sections 15 and 16.
+
+     If the disclaimer of warranty and limitation of liability provided
+     above cannot be given local legal effect according to their terms,
+     reviewing courts shall apply local law that most closely
+     approximates an absolute waiver of all civil liability in
+     connection with the Program, unless a warranty or assumption of
+     liability accompanies a copy of the Program in return for a fee.
+
+
+END OF TERMS AND CONDITIONS
+===========================
+
+How to Apply These Terms to Your New Programs
+=============================================
+
+If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+
+   To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+     ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
+     Copyright (C) YEAR NAME OF AUTHOR
+
+     This program is free software: you can redistribute it and/or modify
+     it under the terms of the GNU General Public License as published by
+     the Free Software Foundation, either version 3 of the License, or (at
+     your option) any later version.
+
+     This program is distributed in the hope that it will be useful, but
+     WITHOUT ANY WARRANTY; without even the implied warranty of
+     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+     General Public License for more details.
+
+     You should have received a copy of the GNU General Public License
+     along with this program.  If not, see `http://www.gnu.org/licenses/'.
+
+   Also add information on how to contact you by electronic and paper
+mail.
+
+   If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+     PROGRAM Copyright (C) YEAR NAME OF AUTHOR
+     This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+     This is free software, and you are welcome to redistribute it
+     under certain conditions; type `show c' for details.
+
+   The hypothetical commands `show w' and `show c' should show the
+appropriate parts of the General Public License.  Of course, your
+program's commands might be different; for a GUI interface, you would
+use an "about box".
+
+   You should also get your employer (if you work as a programmer) or
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  For more information on this, and how to apply and follow
+the GNU GPL, see `http://www.gnu.org/licenses/'.
+
+   The GNU General Public License does not permit incorporating your
+program into proprietary programs.  If your program is a subroutine
+library, you may consider it more useful to permit linking proprietary
+applications with the library.  If this is what you want to do, use the
+GNU Lesser General Public License instead of this License.  But first,
+please read `http://www.gnu.org/philosophy/why-not-lgpl.html'.
+
+
+File: bison.info,  Node: Concepts,  Next: Examples,  Prev: Copying,  Up: Top
+
+1 The Concepts of Bison
+***********************
+
+This chapter introduces many of the basic concepts without which the
+details of Bison will not make sense.  If you do not already know how to
+use Bison or Yacc, we suggest you start by reading this chapter
+carefully.
+
+* Menu:
+
+* Language and Grammar:: Languages and context-free grammars,
+                           as mathematical ideas.
+* Grammar in Bison::     How we represent grammars for Bison's sake.
+* Semantic Values::      Each token or syntactic grouping can have
+                           a semantic value (the value of an integer,
+                           the name of an identifier, etc.).
+* Semantic Actions::     Each rule can have an action containing C code.
+* GLR Parsers::          Writing parsers for general context-free languages.
+* Locations Overview::   Tracking Locations.
+* Bison Parser::         What are Bison's input and output,
+                           how is the output used?
+* Stages::               Stages in writing and running Bison grammars.
+* Grammar Layout::       Overall structure of a Bison grammar file.
+
+
+File: bison.info,  Node: Language and Grammar,  Next: Grammar in Bison,  Up: Concepts
+
+1.1 Languages and Context-Free Grammars
+=======================================
+
+In order for Bison to parse a language, it must be described by a
+"context-free grammar".  This means that you specify one or more
+"syntactic groupings" and give rules for constructing them from their
+parts.  For example, in the C language, one kind of grouping is called
+an `expression'.  One rule for making an expression might be, "An
+expression can be made of a minus sign and another expression".
+Another would be, "An expression can be an integer".  As you can see,
+rules are often recursive, but there must be at least one rule which
+leads out of the recursion.
+
+   The most common formal system for presenting such rules for humans
+to read is "Backus-Naur Form" or "BNF", which was developed in order to
+specify the language Algol 60.  Any grammar expressed in BNF is a
+context-free grammar.  The input to Bison is essentially
+machine-readable BNF.
+
+   There are various important subclasses of context-free grammar.
+Although it can handle almost all context-free grammars, Bison is
+optimized for what are called LALR(1) grammars.  In brief, in these
+grammars, it must be possible to tell how to parse any portion of an
+input string with just a single token of lookahead.  Strictly speaking,
+that is a description of an LR(1) grammar, and LALR(1) involves
+additional restrictions that are hard to explain simply; but it is rare
+in actual practice to find an LR(1) grammar that fails to be LALR(1).
+*Note Mysterious Reduce/Reduce Conflicts: Mystery Conflicts, for more
+information on this.
+
+   Parsers for LALR(1) grammars are "deterministic", meaning roughly
+that the next grammar rule to apply at any point in the input is
+uniquely determined by the preceding input and a fixed, finite portion
+(called a "lookahead") of the remaining input.  A context-free grammar
+can be "ambiguous", meaning that there are multiple ways to apply the
+grammar rules to get the same inputs.  Even unambiguous grammars can be
+"nondeterministic", meaning that no fixed lookahead always suffices to
+determine the next grammar rule to apply.  With the proper
+declarations, Bison is also able to parse these more general
+context-free grammars, using a technique known as GLR parsing (for
+Generalized LR).  Bison's GLR parsers are able to handle any
+context-free grammar for which the number of possible parses of any
+given string is finite.
+
+   In the formal grammatical rules for a language, each kind of
+syntactic unit or grouping is named by a "symbol".  Those which are
+built by grouping smaller constructs according to grammatical rules are
+called "nonterminal symbols"; those which can't be subdivided are called
+"terminal symbols" or "token types".  We call a piece of input
+corresponding to a single terminal symbol a "token", and a piece
+corresponding to a single nonterminal symbol a "grouping".
+
+   We can use the C language as an example of what symbols, terminal and
+nonterminal, mean.  The tokens of C are identifiers, constants (numeric
+and string), and the various keywords, arithmetic operators and
+punctuation marks.  So the terminal symbols of a grammar for C include
+`identifier', `number', `string', plus one symbol for each keyword,
+operator or punctuation mark: `if', `return', `const', `static', `int',
+`char', `plus-sign', `open-brace', `close-brace', `comma' and many more.
+(These tokens can be subdivided into characters, but that is a matter of
+lexicography, not grammar.)
+
+   Here is a simple C function subdivided into tokens:
+
+     int             /* keyword `int' */
+     square (int x)  /* identifier, open-paren, keyword `int',
+                        identifier, close-paren */
+     {               /* open-brace */
+       return x * x; /* keyword `return', identifier, asterisk,
+                        identifier, semicolon */
+     }               /* close-brace */
+
+   The syntactic groupings of C include the expression, the statement,
+the declaration, and the function definition.  These are represented in
+the grammar of C by nonterminal symbols `expression', `statement',
+`declaration' and `function definition'.  The full grammar uses dozens
+of additional language constructs, each with its own nonterminal
+symbol, in order to express the meanings of these four.  The example
+above is a function definition; it contains one declaration, and one
+statement.  In the statement, each `x' is an expression and so is `x *
+x'.
+
+   Each nonterminal symbol must have grammatical rules showing how it
+is made out of simpler constructs.  For example, one kind of C
+statement is the `return' statement; this would be described with a
+grammar rule which reads informally as follows:
+
+     A `statement' can be made of a `return' keyword, an `expression'
+     and a `semicolon'.
+
+There would be many other rules for `statement', one for each kind of
+statement in C.
+
+   One nonterminal symbol must be distinguished as the special one which
+defines a complete utterance in the language.  It is called the "start
+symbol".  In a compiler, this means a complete input program.  In the C
+language, the nonterminal symbol `sequence of definitions and
+declarations' plays this role.
+
+   For example, `1 + 2' is a valid C expression--a valid part of a C
+program--but it is not valid as an _entire_ C program.  In the
+context-free grammar of C, this follows from the fact that `expression'
+is not the start symbol.
+
+   The Bison parser reads a sequence of tokens as its input, and groups
+the tokens using the grammar rules.  If the input is valid, the end
+result is that the entire token sequence reduces to a single grouping
+whose symbol is the grammar's start symbol.  If we use a grammar for C,
+the entire input must be a `sequence of definitions and declarations'.
+If not, the parser reports a syntax error.
+
+
+File: bison.info,  Node: Grammar in Bison,  Next: Semantic Values,  Prev: Language and Grammar,  Up: Concepts
+
+1.2 From Formal Rules to Bison Input
+====================================
+
+A formal grammar is a mathematical construct.  To define the language
+for Bison, you must write a file expressing the grammar in Bison syntax:
+a "Bison grammar" file.  *Note Bison Grammar Files: Grammar File.
+
+   A nonterminal symbol in the formal grammar is represented in Bison
+input as an identifier, like an identifier in C.  By convention, it
+should be in lower case, such as `expr', `stmt' or `declaration'.
+
+   The Bison representation for a terminal symbol is also called a
+"token type".  Token types as well can be represented as C-like
+identifiers.  By convention, these identifiers should be upper case to
+distinguish them from nonterminals: for example, `INTEGER',
+`IDENTIFIER', `IF' or `RETURN'.  A terminal symbol that stands for a
+particular keyword in the language should be named after that keyword
+converted to upper case.  The terminal symbol `error' is reserved for
+error recovery.  *Note Symbols::.
+
+   A terminal symbol can also be represented as a character literal,
+just like a C character constant.  You should do this whenever a token
+is just a single character (parenthesis, plus-sign, etc.): use that
+same character in a literal as the terminal symbol for that token.
+
+   A third way to represent a terminal symbol is with a C string
+constant containing several characters.  *Note Symbols::, for more
+information.
+
+   The grammar rules also have an expression in Bison syntax.  For
+example, here is the Bison rule for a C `return' statement.  The
+semicolon in quotes is a literal character token, representing part of
+the C syntax for the statement; the naked semicolon, and the colon, are
+Bison punctuation used in every rule.
+
+     stmt:   RETURN expr ';'
+             ;
+
+*Note Syntax of Grammar Rules: Rules.
+
+
+File: bison.info,  Node: Semantic Values,  Next: Semantic Actions,  Prev: Grammar in Bison,  Up: Concepts
+
+1.3 Semantic Values
+===================
+
+A formal grammar selects tokens only by their classifications: for
+example, if a rule mentions the terminal symbol `integer constant', it
+means that _any_ integer constant is grammatically valid in that
+position.  The precise value of the constant is irrelevant to how to
+parse the input: if `x+4' is grammatical then `x+1' or `x+3989' is
+equally grammatical.
+
+   But the precise value is very important for what the input means
+once it is parsed.  A compiler is useless if it fails to distinguish
+between 4, 1 and 3989 as constants in the program!  Therefore, each
+token in a Bison grammar has both a token type and a "semantic value".
+*Note Defining Language Semantics: Semantics, for details.
+
+   The token type is a terminal symbol defined in the grammar, such as
+`INTEGER', `IDENTIFIER' or `',''.  It tells everything you need to know
+to decide where the token may validly appear and how to group it with
+other tokens.  The grammar rules know nothing about tokens except their
+types.
+
+   The semantic value has all the rest of the information about the
+meaning of the token, such as the value of an integer, or the name of an
+identifier.  (A token such as `','' which is just punctuation doesn't
+need to have any semantic value.)
+
+   For example, an input token might be classified as token type
+`INTEGER' and have the semantic value 4.  Another input token might
+have the same token type `INTEGER' but value 3989.  When a grammar rule
+says that `INTEGER' is allowed, either of these tokens is acceptable
+because each is an `INTEGER'.  When the parser accepts the token, it
+keeps track of the token's semantic value.
+
+   Each grouping can also have a semantic value as well as its
+nonterminal symbol.  For example, in a calculator, an expression
+typically has a semantic value that is a number.  In a compiler for a
+programming language, an expression typically has a semantic value that
+is a tree structure describing the meaning of the expression.
+
+
+File: bison.info,  Node: Semantic Actions,  Next: GLR Parsers,  Prev: Semantic Values,  Up: Concepts
+
+1.4 Semantic Actions
+====================
+
+In order to be useful, a program must do more than parse input; it must
+also produce some output based on the input.  In a Bison grammar, a
+grammar rule can have an "action" made up of C statements.  Each time
+the parser recognizes a match for that rule, the action is executed.
+*Note Actions::.
+
+   Most of the time, the purpose of an action is to compute the
+semantic value of the whole construct from the semantic values of its
+parts.  For example, suppose we have a rule which says an expression
+can be the sum of two expressions.  When the parser recognizes such a
+sum, each of the subexpressions has a semantic value which describes
+how it was built up.  The action for this rule should create a similar
+sort of value for the newly recognized larger expression.
+
+   For example, here is a rule that says an expression can be the sum of
+two subexpressions:
+
+     expr: expr '+' expr   { $$ = $1 + $3; }
+             ;
+
+The action says how to produce the semantic value of the sum expression
+from the values of the two subexpressions.
+
+
+File: bison.info,  Node: GLR Parsers,  Next: Locations Overview,  Prev: Semantic Actions,  Up: Concepts
+
+1.5 Writing GLR Parsers
+=======================
+
+In some grammars, Bison's standard LALR(1) parsing algorithm cannot
+decide whether to apply a certain grammar rule at a given point.  That
+is, it may not be able to decide (on the basis of the input read so
+far) which of two possible reductions (applications of a grammar rule)
+applies, or whether to apply a reduction or read more of the input and
+apply a reduction later in the input.  These are known respectively as
+"reduce/reduce" conflicts (*note Reduce/Reduce::), and "shift/reduce"
+conflicts (*note Shift/Reduce::).
+
+   To use a grammar that is not easily modified to be LALR(1), a more
+general parsing algorithm is sometimes necessary.  If you include
+`%glr-parser' among the Bison declarations in your file (*note Grammar
+Outline::), the result is a Generalized LR (GLR) parser.  These parsers
+handle Bison grammars that contain no unresolved conflicts (i.e., after
+applying precedence declarations) identically to LALR(1) parsers.
+However, when faced with unresolved shift/reduce and reduce/reduce
+conflicts, GLR parsers use the simple expedient of doing both,
+effectively cloning the parser to follow both possibilities.  Each of
+the resulting parsers can again split, so that at any given time, there
+can be any number of possible parses being explored.  The parsers
+proceed in lockstep; that is, all of them consume (shift) a given input
+symbol before any of them proceed to the next.  Each of the cloned
+parsers eventually meets one of two possible fates: either it runs into
+a parsing error, in which case it simply vanishes, or it merges with
+another parser, because the two of them have reduced the input to an
+identical set of symbols.
+
+   During the time that there are multiple parsers, semantic actions are
+recorded, but not performed.  When a parser disappears, its recorded
+semantic actions disappear as well, and are never performed.  When a
+reduction makes two parsers identical, causing them to merge, Bison
+records both sets of semantic actions.  Whenever the last two parsers
+merge, reverting to the single-parser case, Bison resolves all the
+outstanding actions either by precedences given to the grammar rules
+involved, or by performing both actions, and then calling a designated
+user-defined function on the resulting values to produce an arbitrary
+merged result.
+
+* Menu:
+
+* Simple GLR Parsers::     Using GLR parsers on unambiguous grammars.
+* Merging GLR Parses::     Using GLR parsers to resolve ambiguities.
+* GLR Semantic Actions::   Deferred semantic actions have special concerns.
+* Compiler Requirements::  GLR parsers require a modern C compiler.
+
+
+File: bison.info,  Node: Simple GLR Parsers,  Next: Merging GLR Parses,  Up: GLR Parsers
+
+1.5.1 Using GLR on Unambiguous Grammars
+---------------------------------------
+
+In the simplest cases, you can use the GLR algorithm to parse grammars
+that are unambiguous, but fail to be LALR(1).  Such grammars typically
+require more than one symbol of lookahead, or (in rare cases) fall into
+the category of grammars in which the LALR(1) algorithm throws away too
+much information (they are in LR(1), but not LALR(1), *Note Mystery
+Conflicts::).
+
+   Consider a problem that arises in the declaration of enumerated and
+subrange types in the programming language Pascal.  Here are some
+examples:
+
+     type subrange = lo .. hi;
+     type enum = (a, b, c);
+
+The original language standard allows only numeric literals and
+constant identifiers for the subrange bounds (`lo' and `hi'), but
+Extended Pascal (ISO/IEC 10206) and many other Pascal implementations
+allow arbitrary expressions there.  This gives rise to the following
+situation, containing a superfluous pair of parentheses:
+
+     type subrange = (a) .. b;
+
+Compare this to the following declaration of an enumerated type with
+only one value:
+
+     type enum = (a);
+
+(These declarations are contrived, but they are syntactically valid,
+and more-complicated cases can come up in practical programs.)
+
+   These two declarations look identical until the `..' token.  With
+normal LALR(1) one-token lookahead it is not possible to decide between
+the two forms when the identifier `a' is parsed.  It is, however,
+desirable for a parser to decide this, since in the latter case `a'
+must become a new identifier to represent the enumeration value, while
+in the former case `a' must be evaluated with its current meaning,
+which may be a constant or even a function call.
+
+   You could parse `(a)' as an "unspecified identifier in parentheses",
+to be resolved later, but this typically requires substantial
+contortions in both semantic actions and large parts of the grammar,
+where the parentheses are nested in the recursive rules for expressions.
+
+   You might think of using the lexer to distinguish between the two
+forms by returning different tokens for currently defined and undefined
+identifiers.  But if these declarations occur in a local scope, and `a'
+is defined in an outer scope, then both forms are possible--either
+locally redefining `a', or using the value of `a' from the outer scope.
+So this approach cannot work.
+
+   A simple solution to this problem is to declare the parser to use
+the GLR algorithm.  When the GLR parser reaches the critical state, it
+merely splits into two branches and pursues both syntax rules
+simultaneously.  Sooner or later, one of them runs into a parsing
+error.  If there is a `..' token before the next `;', the rule for
+enumerated types fails since it cannot accept `..' anywhere; otherwise,
+the subrange type rule fails since it requires a `..' token.  So one of
+the branches fails silently, and the other one continues normally,
+performing all the intermediate actions that were postponed during the
+split.
+
+   If the input is syntactically incorrect, both branches fail and the
+parser reports a syntax error as usual.
+
+   The effect of all this is that the parser seems to "guess" the
+correct branch to take, or in other words, it seems to use more
+lookahead than the underlying LALR(1) algorithm actually allows for.
+In this example, LALR(2) would suffice, but also some cases that are
+not LALR(k) for any k can be handled this way.
+
+   In general, a GLR parser can take quadratic or cubic worst-case time,
+and the current Bison parser even takes exponential time and space for
+some grammars.  In practice, this rarely happens, and for many grammars
+it is possible to prove that it cannot happen.  The present example
+contains only one conflict between two rules, and the type-declaration
+context containing the conflict cannot be nested.  So the number of
+branches that can exist at any time is limited by the constant 2, and
+the parsing time is still linear.
+
+   Here is a Bison grammar corresponding to the example above.  It
+parses a vastly simplified form of Pascal type declarations.
+
+     %token TYPE DOTDOT ID
+
+     %left '+' '-'
+     %left '*' '/'
+
+     %%
+
+     type_decl : TYPE ID '=' type ';'
+          ;
+
+     type : '(' id_list ')'
+          | expr DOTDOT expr
+          ;
+
+     id_list : ID
+          | id_list ',' ID
+          ;
+
+     expr : '(' expr ')'
+          | expr '+' expr
+          | expr '-' expr
+          | expr '*' expr
+          | expr '/' expr
+          | ID
+          ;
+
+   When used as a normal LALR(1) grammar, Bison correctly complains
+about one reduce/reduce conflict.  In the conflicting situation the
+parser chooses one of the alternatives, arbitrarily the one declared
+first.  Therefore the following correct input is not recognized:
+
+     type t = (a) .. b;
+
+   The parser can be turned into a GLR parser, while also telling Bison
+to be silent about the one known reduce/reduce conflict, by adding
+these two declarations to the Bison input file (before the first `%%'):
+
+     %glr-parser
+     %expect-rr 1
+
+No change in the grammar itself is required.  Now the parser recognizes
+all valid declarations, according to the limited syntax above,
+transparently.  In fact, the user does not even notice when the parser
+splits.
+
+   So here we have a case where we can use the benefits of GLR, almost
+without disadvantages.  Even in simple cases like this, however, there
+are at least two potential problems to beware.  First, always analyze
+the conflicts reported by Bison to make sure that GLR splitting is only
+done where it is intended.  A GLR parser splitting inadvertently may
+cause problems less obvious than an LALR parser statically choosing the
+wrong alternative in a conflict.  Second, consider interactions with
+the lexer (*note Semantic Tokens::) with great care.  Since a split
+parser consumes tokens without performing any actions during the split,
+the lexer cannot obtain information via parser actions.  Some cases of
+lexer interactions can be eliminated by using GLR to shift the
+complications from the lexer to the parser.  You must check the
+remaining cases for correctness.
+
+   In our example, it would be safe for the lexer to return tokens
+based on their current meanings in some symbol table, because no new
+symbols are defined in the middle of a type declaration.  Though it is
+possible for a parser to define the enumeration constants as they are
+parsed, before the type declaration is completed, it actually makes no
+difference since they cannot be used within the same enumerated type
+declaration.
+
+
+File: bison.info,  Node: Merging GLR Parses,  Next: GLR Semantic Actions,  Prev: Simple GLR Parsers,  Up: GLR Parsers
+
+1.5.2 Using GLR to Resolve Ambiguities
+--------------------------------------
+
+Let's consider an example, vastly simplified from a C++ grammar.
+
+     %{
+       #include <stdio.h>
+       #define YYSTYPE char const *
+       int yylex (void);
+       void yyerror (char const *);
+     %}
+
+     %token TYPENAME ID
+
+     %right '='
+     %left '+'
+
+     %glr-parser
+
+     %%
+
+     prog :
+          | prog stmt   { printf ("\n"); }
+          ;
+
+     stmt : expr ';'  %dprec 1
+          | decl      %dprec 2
+          ;
+
+     expr : ID               { printf ("%s ", $$); }
+          | TYPENAME '(' expr ')'
+                             { printf ("%s <cast> ", $1); }
+          | expr '+' expr    { printf ("+ "); }
+          | expr '=' expr    { printf ("= "); }
+          ;
+
+     decl : TYPENAME declarator ';'
+                             { printf ("%s <declare> ", $1); }
+          | TYPENAME declarator '=' expr ';'
+                             { printf ("%s <init-declare> ", $1); }
+          ;
+
+     declarator : ID         { printf ("\"%s\" ", $1); }
+          | '(' declarator ')'
+          ;
+
+This models a problematic part of the C++ grammar--the ambiguity between
+certain declarations and statements.  For example,
+
+     T (x) = y+z;
+
+parses as either an `expr' or a `stmt' (assuming that `T' is recognized
+as a `TYPENAME' and `x' as an `ID').  Bison detects this as a
+reduce/reduce conflict between the rules `expr : ID' and `declarator :
+ID', which it cannot resolve at the time it encounters `x' in the
+example above.  Since this is a GLR parser, it therefore splits the
+problem into two parses, one for each choice of resolving the
+reduce/reduce conflict.  Unlike the example from the previous section
+(*note Simple GLR Parsers::), however, neither of these parses "dies,"
+because the grammar as it stands is ambiguous.  One of the parsers
+eventually reduces `stmt : expr ';'' and the other reduces `stmt :
+decl', after which both parsers are in an identical state: they've seen
+`prog stmt' and have the same unprocessed input remaining.  We say that
+these parses have "merged."
+
+   At this point, the GLR parser requires a specification in the
+grammar of how to choose between the competing parses.  In the example
+above, the two `%dprec' declarations specify that Bison is to give
+precedence to the parse that interprets the example as a `decl', which
+implies that `x' is a declarator.  The parser therefore prints
+
+     "x" y z + T <init-declare>
+
+   The `%dprec' declarations only come into play when more than one
+parse survives.  Consider a different input string for this parser:
+
+     T (x) + y;
+
+This is another example of using GLR to parse an unambiguous construct,
+as shown in the previous section (*note Simple GLR Parsers::).  Here,
+there is no ambiguity (this cannot be parsed as a declaration).
+However, at the time the Bison parser encounters `x', it does not have
+enough information to resolve the reduce/reduce conflict (again,
+between `x' as an `expr' or a `declarator').  In this case, no
+precedence declaration is used.  Again, the parser splits into two, one
+assuming that `x' is an `expr', and the other assuming `x' is a
+`declarator'.  The second of these parsers then vanishes when it sees
+`+', and the parser prints
+
+     x T <cast> y +
+
+   Suppose that instead of resolving the ambiguity, you wanted to see
+all the possibilities.  For this purpose, you must merge the semantic
+actions of the two possible parsers, rather than choosing one over the
+other.  To do so, you could change the declaration of `stmt' as follows:
+
+     stmt : expr ';'  %merge <stmtMerge>
+          | decl      %merge <stmtMerge>
+          ;
+
+and define the `stmtMerge' function as:
+
+     static YYSTYPE
+     stmtMerge (YYSTYPE x0, YYSTYPE x1)
+     {
+       printf ("<OR> ");
+       return "";
+     }
+
+with an accompanying forward declaration in the C declarations at the
+beginning of the file:
+
+     %{
+       #define YYSTYPE char const *
+       static YYSTYPE stmtMerge (YYSTYPE x0, YYSTYPE x1);
+     %}
+
+With these declarations, the resulting parser parses the first example
+as both an `expr' and a `decl', and prints
+
+     "x" y z + T <init-declare> x T <cast> y z + = <OR>
+
+   Bison requires that all of the productions that participate in any
+particular merge have identical `%merge' clauses.  Otherwise, the
+ambiguity would be unresolvable, and the parser will report an error
+during any parse that results in the offending merge.
+
+
+File: bison.info,  Node: GLR Semantic Actions,  Next: Compiler Requirements,  Prev: Merging GLR Parses,  Up: GLR Parsers
+
+1.5.3 GLR Semantic Actions
+--------------------------
+
+By definition, a deferred semantic action is not performed at the same
+time as the associated reduction.  This raises caveats for several
+Bison features you might use in a semantic action in a GLR parser.
+
+   In any semantic action, you can examine `yychar' to determine the
+type of the lookahead token present at the time of the associated
+reduction.  After checking that `yychar' is not set to `YYEMPTY' or
+`YYEOF', you can then examine `yylval' and `yylloc' to determine the
+lookahead token's semantic value and location, if any.  In a
+nondeferred semantic action, you can also modify any of these variables
+to influence syntax analysis.  *Note Lookahead Tokens: Lookahead.
+
+   In a deferred semantic action, it's too late to influence syntax
+analysis.  In this case, `yychar', `yylval', and `yylloc' are set to
+shallow copies of the values they had at the time of the associated
+reduction.  For this reason alone, modifying them is dangerous.
+Moreover, the result of modifying them is undefined and subject to
+change with future versions of Bison.  For example, if a semantic
+action might be deferred, you should never write it to invoke
+`yyclearin' (*note Action Features::) or to attempt to free memory
+referenced by `yylval'.
+
+   Another Bison feature requiring special consideration is `YYERROR'
+(*note Action Features::), which you can invoke in a semantic action to
+initiate error recovery.  During deterministic GLR operation, the
+effect of `YYERROR' is the same as its effect in an LALR(1) parser.  In
+a deferred semantic action, its effect is undefined.
+
+   Also, see *Note Default Action for Locations: Location Default
+Action, which describes a special usage of `YYLLOC_DEFAULT' in GLR
+parsers.
+
+
+File: bison.info,  Node: Compiler Requirements,  Prev: GLR Semantic Actions,  Up: GLR Parsers
+
+1.5.4 Considerations when Compiling GLR Parsers
+-----------------------------------------------
+
+The GLR parsers require a compiler for ISO C89 or later.  In addition,
+they use the `inline' keyword, which is not C89, but is C99 and is a
+common extension in pre-C99 compilers.  It is up to the user of these
+parsers to handle portability issues.  For instance, if using Autoconf
+and the Autoconf macro `AC_C_INLINE', a mere
+
+     %{
+       #include <config.h>
+     %}
+
+will suffice.  Otherwise, we suggest
+
+     %{
+       #if __STDC_VERSION__ < 199901 && ! defined __GNUC__ && ! defined inline
+        #define inline
+       #endif
+     %}
+
+
+File: bison.info,  Node: Locations Overview,  Next: Bison Parser,  Prev: GLR Parsers,  Up: Concepts
+
+1.6 Locations
+=============
+
+Many applications, like interpreters or compilers, have to produce
+verbose and useful error messages.  To achieve this, one must be able
+to keep track of the "textual location", or "location", of each
+syntactic construct.  Bison provides a mechanism for handling these
+locations.
+
+   Each token has a semantic value.  In a similar fashion, each token
+has an associated location, but the type of locations is the same for
+all tokens and groupings.  Moreover, the output parser is equipped with
+a default data structure for storing locations (*note Locations::, for
+more details).
+
+   Like semantic values, locations can be reached in actions using a
+dedicated set of constructs.  In the example above, the location of the
+whole grouping is `@$', while the locations of the subexpressions are
+`@1' and `@3'.
+
+   When a rule is matched, a default action is used to compute the
+semantic value of its left hand side (*note Actions::).  In the same
+way, another default action is used for locations.  However, the action
+for locations is general enough for most cases, meaning there is
+usually no need to describe for each rule how `@$' should be formed.
+When building a new location for a given grouping, the default behavior
+of the output parser is to take the beginning of the first symbol, and
+the end of the last symbol.
+
+
+File: bison.info,  Node: Bison Parser,  Next: Stages,  Prev: Locations Overview,  Up: Concepts
+
+1.7 Bison Output: the Parser File
+=================================
+
+When you run Bison, you give it a Bison grammar file as input.  The
+output is a C source file that parses the language described by the
+grammar.  This file is called a "Bison parser".  Keep in mind that the
+Bison utility and the Bison parser are two distinct programs: the Bison
+utility is a program whose output is the Bison parser that becomes part
+of your program.
+
+   The job of the Bison parser is to group tokens into groupings
+according to the grammar rules--for example, to build identifiers and
+operators into expressions.  As it does this, it runs the actions for
+the grammar rules it uses.
+
+   The tokens come from a function called the "lexical analyzer" that
+you must supply in some fashion (such as by writing it in C).  The Bison
+parser calls the lexical analyzer each time it wants a new token.  It
+doesn't know what is "inside" the tokens (though their semantic values
+may reflect this).  Typically the lexical analyzer makes the tokens by
+parsing characters of text, but Bison does not depend on this.  *Note
+The Lexical Analyzer Function `yylex': Lexical.
+
+   The Bison parser file is C code which defines a function named
+`yyparse' which implements that grammar.  This function does not make a
+complete C program: you must supply some additional functions.  One is
+the lexical analyzer.  Another is an error-reporting function which the
+parser calls to report an error.  In addition, a complete C program must
+start with a function called `main'; you have to provide this, and
+arrange for it to call `yyparse' or the parser will never run.  *Note
+Parser C-Language Interface: Interface.
+
+   Aside from the token type names and the symbols in the actions you
+write, all symbols defined in the Bison parser file itself begin with
+`yy' or `YY'.  This includes interface functions such as the lexical
+analyzer function `yylex', the error reporting function `yyerror' and
+the parser function `yyparse' itself.  This also includes numerous
+identifiers used for internal purposes.  Therefore, you should avoid
+using C identifiers starting with `yy' or `YY' in the Bison grammar
+file except for the ones defined in this manual.  Also, you should
+avoid using the C identifiers `malloc' and `free' for anything other
+than their usual meanings.
+
+   In some cases the Bison parser file includes system headers, and in
+those cases your code should respect the identifiers reserved by those
+headers.  On some non-GNU hosts, `<alloca.h>', `<malloc.h>',
+`<stddef.h>', and `<stdlib.h>' are included as needed to declare memory
+allocators and related types.  `<libintl.h>' is included if message
+translation is in use (*note Internationalization::).  Other system
+headers may be included if you define `YYDEBUG' to a nonzero value
+(*note Tracing Your Parser: Tracing.).
+
+
+File: bison.info,  Node: Stages,  Next: Grammar Layout,  Prev: Bison Parser,  Up: Concepts
+
+1.8 Stages in Using Bison
+=========================
+
+The actual language-design process using Bison, from grammar
+specification to a working compiler or interpreter, has these parts:
+
+  1. Formally specify the grammar in a form recognized by Bison (*note
+     Bison Grammar Files: Grammar File.).  For each grammatical rule in
+     the language, describe the action that is to be taken when an
+     instance of that rule is recognized.  The action is described by a
+     sequence of C statements.
+
+  2. Write a lexical analyzer to process input and pass tokens to the
+     parser.  The lexical analyzer may be written by hand in C (*note
+     The Lexical Analyzer Function `yylex': Lexical.).  It could also
+     be produced using Lex, but the use of Lex is not discussed in this
+     manual.
+
+  3. Write a controlling function that calls the Bison-produced parser.
+
+  4. Write error-reporting routines.
+
+   To turn this source code as written into a runnable program, you
+must follow these steps:
+
+  1. Run Bison on the grammar to produce the parser.
+
+  2. Compile the code output by Bison, as well as any other source
+     files.
+
+  3. Link the object files to produce the finished product.
+
+
+File: bison.info,  Node: Grammar Layout,  Prev: Stages,  Up: Concepts
+
+1.9 The Overall Layout of a Bison Grammar
+=========================================
+
+The input file for the Bison utility is a "Bison grammar file".  The
+general form of a Bison grammar file is as follows:
+
+     %{
+     PROLOGUE
+     %}
+
+     BISON DECLARATIONS
+
+     %%
+     GRAMMAR RULES
+     %%
+     EPILOGUE
+
+The `%%', `%{' and `%}' are punctuation that appears in every Bison
+grammar file to separate the sections.
+
+   The prologue may define types and variables used in the actions.
+You can also use preprocessor commands to define macros used there, and
+use `#include' to include header files that do any of these things.
+You need to declare the lexical analyzer `yylex' and the error printer
+`yyerror' here, along with any other global identifiers used by the
+actions in the grammar rules.
+
+   The Bison declarations declare the names of the terminal and
+nonterminal symbols, and may also describe operator precedence and the
+data types of semantic values of various symbols.
+
+   The grammar rules define how to construct each nonterminal symbol
+from its parts.
+
+   The epilogue can contain any code you want to use.  Often the
+definitions of functions declared in the prologue go here.  In a simple
+program, all the rest of the program can go here.
+
+
+File: bison.info,  Node: Examples,  Next: Grammar File,  Prev: Concepts,  Up: Top
+
+2 Examples
+**********
+
+Now we show and explain three sample programs written using Bison: a
+reverse polish notation calculator, an algebraic (infix) notation
+calculator, and a multi-function calculator.  All three have been tested
+under BSD Unix 4.3; each produces a usable, though limited, interactive
+desk-top calculator.
+
+   These examples are simple, but Bison grammars for real programming
+languages are written the same way.  You can copy these examples into a
+source file to try them.
+
+* Menu:
+
+* RPN Calc::               Reverse polish notation calculator;
+                             a first example with no operator precedence.
+* Infix Calc::             Infix (algebraic) notation calculator.
+                             Operator precedence is introduced.
+* Simple Error Recovery::  Continuing after syntax errors.
+* Location Tracking Calc:: Demonstrating the use of @N and @$.
+* Multi-function Calc::    Calculator with memory and trig functions.
+                             It uses multiple data-types for semantic values.
+* Exercises::              Ideas for improving the multi-function calculator.
+
+
+File: bison.info,  Node: RPN Calc,  Next: Infix Calc,  Up: Examples
+
+2.1 Reverse Polish Notation Calculator
+======================================
+
+The first example is that of a simple double-precision "reverse polish
+notation" calculator (a calculator using postfix operators).  This
+example provides a good starting point, since operator precedence is
+not an issue.  The second example will illustrate how operator
+precedence is handled.
+
+   The source code for this calculator is named `rpcalc.y'.  The `.y'
+extension is a convention used for Bison input files.
+
+* Menu:
+
+* Rpcalc Declarations::    Prologue (declarations) for rpcalc.
+* Rpcalc Rules::           Grammar Rules for rpcalc, with explanation.
+* Rpcalc Lexer::           The lexical analyzer.
+* Rpcalc Main::            The controlling function.
+* Rpcalc Error::           The error reporting function.
+* Rpcalc Generate::        Running Bison on the grammar file.
+* Rpcalc Compile::         Run the C compiler on the output code.
+
+
+File: bison.info,  Node: Rpcalc Declarations,  Next: Rpcalc Rules,  Up: RPN Calc
+
+2.1.1 Declarations for `rpcalc'
+-------------------------------
+
+Here are the C and Bison declarations for the reverse polish notation
+calculator.  As in C, comments are placed between `/*...*/'.
+
+     /* Reverse polish notation calculator.  */
+
+     %{
+       #define YYSTYPE double
+       #include <math.h>
+       int yylex (void);
+       void yyerror (char const *);
+     %}
+
+     %token NUM
+
+     %% /* Grammar rules and actions follow.  */
+
+   The declarations section (*note The prologue: Prologue.) contains two
+preprocessor directives and two forward declarations.
+
+   The `#define' directive defines the macro `YYSTYPE', thus specifying
+the C data type for semantic values of both tokens and groupings (*note
+Data Types of Semantic Values: Value Type.).  The Bison parser will use
+whatever type `YYSTYPE' is defined as; if you don't define it, `int' is
+the default.  Because we specify `double', each token and each
+expression has an associated value, which is a floating point number.
+
+   The `#include' directive is used to declare the exponentiation
+function `pow'.
+
+   The forward declarations for `yylex' and `yyerror' are needed
+because the C language requires that functions be declared before they
+are used.  These functions will be defined in the epilogue, but the
+parser calls them so they must be declared in the prologue.
+
+   The second section, Bison declarations, provides information to Bison
+about the token types (*note The Bison Declarations Section: Bison
+Declarations.).  Each terminal symbol that is not a single-character
+literal must be declared here.  (Single-character literals normally
+don't need to be declared.)  In this example, all the arithmetic
+operators are designated by single-character literals, so the only
+terminal symbol that needs to be declared is `NUM', the token type for
+numeric constants.
+
+
+File: bison.info,  Node: Rpcalc Rules,  Next: Rpcalc Lexer,  Prev: Rpcalc Declarations,  Up: RPN Calc
+
+2.1.2 Grammar Rules for `rpcalc'
+--------------------------------
+
+Here are the grammar rules for the reverse polish notation calculator.
+
+     input:    /* empty */
+             | input line
+     ;
+
+     line:     '\n'
+             | exp '\n'      { printf ("\t%.10g\n", $1); }
+     ;
+
+     exp:      NUM           { $$ = $1;           }
+             | exp exp '+'   { $$ = $1 + $2;      }
+             | exp exp '-'   { $$ = $1 - $2;      }
+             | exp exp '*'   { $$ = $1 * $2;      }
+             | exp exp '/'   { $$ = $1 / $2;      }
+              /* Exponentiation */
+             | exp exp '^'   { $$ = pow ($1, $2); }
+              /* Unary minus    */
+             | exp 'n'       { $$ = -$1;          }
+     ;
+     %%
+
+   The groupings of the rpcalc "language" defined here are the
+expression (given the name `exp'), the line of input (`line'), and the
+complete input transcript (`input').  Each of these nonterminal symbols
+has several alternate rules, joined by the vertical bar `|' which is
+read as "or".  The following sections explain what these rules mean.
+
+   The semantics of the language is determined by the actions taken
+when a grouping is recognized.  The actions are the C code that appears
+inside braces.  *Note Actions::.
+
+   You must specify these actions in C, but Bison provides the means for
+passing semantic values between the rules.  In each action, the
+pseudo-variable `$$' stands for the semantic value for the grouping
+that the rule is going to construct.  Assigning a value to `$$' is the
+main job of most actions.  The semantic values of the components of the
+rule are referred to as `$1', `$2', and so on.
+
+* Menu:
+
+* Rpcalc Input::
+* Rpcalc Line::
+* Rpcalc Expr::
+
+
+File: bison.info,  Node: Rpcalc Input,  Next: Rpcalc Line,  Up: Rpcalc Rules
+
+2.1.2.1 Explanation of `input'
+..............................
+
+Consider the definition of `input':
+
+     input:    /* empty */
+             | input line
+     ;
+
+   This definition reads as follows: "A complete input is either an
+empty string, or a complete input followed by an input line".  Notice
+that "complete input" is defined in terms of itself.  This definition
+is said to be "left recursive" since `input' appears always as the
+leftmost symbol in the sequence.  *Note Recursive Rules: Recursion.
+
+   The first alternative is empty because there are no symbols between
+the colon and the first `|'; this means that `input' can match an empty
+string of input (no tokens).  We write the rules this way because it is
+legitimate to type `Ctrl-d' right after you start the calculator.  It's
+conventional to put an empty alternative first and write the comment
+`/* empty */' in it.
+
+   The second alternate rule (`input line') handles all nontrivial
+input.  It means, "After reading any number of lines, read one more
+line if possible."  The left recursion makes this rule into a loop.
+Since the first alternative matches empty input, the loop can be
+executed zero or more times.
+
+   The parser function `yyparse' continues to process input until a
+grammatical error is seen or the lexical analyzer says there are no more
+input tokens; we will arrange for the latter to happen at end-of-input.
+
+
+File: bison.info,  Node: Rpcalc Line,  Next: Rpcalc Expr,  Prev: Rpcalc Input,  Up: Rpcalc Rules
+
+2.1.2.2 Explanation of `line'
+.............................
+
+Now consider the definition of `line':
+
+     line:     '\n'
+             | exp '\n'  { printf ("\t%.10g\n", $1); }
+     ;
+
+   The first alternative is a token which is a newline character; this
+means that rpcalc accepts a blank line (and ignores it, since there is
+no action).  The second alternative is an expression followed by a
+newline.  This is the alternative that makes rpcalc useful.  The
+semantic value of the `exp' grouping is the value of `$1' because the
+`exp' in question is the first symbol in the alternative.  The action
+prints this value, which is the result of the computation the user
+asked for.
+
+   This action is unusual because it does not assign a value to `$$'.
+As a consequence, the semantic value associated with the `line' is
+uninitialized (its value will be unpredictable).  This would be a bug if
+that value were ever used, but we don't use it: once rpcalc has printed
+the value of the user's input line, that value is no longer needed.
+
+
+File: bison.info,  Node: Rpcalc Expr,  Prev: Rpcalc Line,  Up: Rpcalc Rules
+
+2.1.2.3 Explanation of `expr'
+.............................
+
+The `exp' grouping has several rules, one for each kind of expression.
+The first rule handles the simplest expressions: those that are just
+numbers.  The second handles an addition-expression, which looks like
+two expressions followed by a plus-sign.  The third handles
+subtraction, and so on.
+
+     exp:      NUM
+             | exp exp '+'     { $$ = $1 + $2;    }
+             | exp exp '-'     { $$ = $1 - $2;    }
+             ...
+             ;
+
+   We have used `|' to join all the rules for `exp', but we could
+equally well have written them separately:
+
+     exp:      NUM ;
+     exp:      exp exp '+'     { $$ = $1 + $2;    } ;
+     exp:      exp exp '-'     { $$ = $1 - $2;    } ;
+             ...
+
+   Most of the rules have actions that compute the value of the
+expression in terms of the value of its parts.  For example, in the
+rule for addition, `$1' refers to the first component `exp' and `$2'
+refers to the second one.  The third component, `'+'', has no meaningful
+associated semantic value, but if it had one you could refer to it as
+`$3'.  When `yyparse' recognizes a sum expression using this rule, the
+sum of the two subexpressions' values is produced as the value of the
+entire expression.  *Note Actions::.
+
+   You don't have to give an action for every rule.  When a rule has no
+action, Bison by default copies the value of `$1' into `$$'.  This is
+what happens in the first rule (the one that uses `NUM').
+
+   The formatting shown here is the recommended convention, but Bison
+does not require it.  You can add or change white space as much as you
+wish.  For example, this:
+
+     exp   : NUM | exp exp '+' {$$ = $1 + $2; } | ... ;
+
+means the same thing as this:
+
+     exp:      NUM
+             | exp exp '+'    { $$ = $1 + $2; }
+             | ...
+     ;
+
+The latter, however, is much more readable.
+
+
+File: bison.info,  Node: Rpcalc Lexer,  Next: Rpcalc Main,  Prev: Rpcalc Rules,  Up: RPN Calc
+
+2.1.3 The `rpcalc' Lexical Analyzer
+-----------------------------------
+
+The lexical analyzer's job is low-level parsing: converting characters
+or sequences of characters into tokens.  The Bison parser gets its
+tokens by calling the lexical analyzer.  *Note The Lexical Analyzer
+Function `yylex': Lexical.
+
+   Only a simple lexical analyzer is needed for the RPN calculator.
+This lexical analyzer skips blanks and tabs, then reads in numbers as
+`double' and returns them as `NUM' tokens.  Any other character that
+isn't part of a number is a separate token.  Note that the token-code
+for such a single-character token is the character itself.
+
+   The return value of the lexical analyzer function is a numeric code
+which represents a token type.  The same text used in Bison rules to
+stand for this token type is also a C expression for the numeric code
+for the type.  This works in two ways.  If the token type is a
+character literal, then its numeric code is that of the character; you
+can use the same character literal in the lexical analyzer to express
+the number.  If the token type is an identifier, that identifier is
+defined by Bison as a C macro whose definition is the appropriate
+number.  In this example, therefore, `NUM' becomes a macro for `yylex'
+to use.
+
+   The semantic value of the token (if it has one) is stored into the
+global variable `yylval', which is where the Bison parser will look for
+it.  (The C data type of `yylval' is `YYSTYPE', which was defined at
+the beginning of the grammar; *note Declarations for `rpcalc': Rpcalc
+Declarations.)
+
+   A token type code of zero is returned if the end-of-input is
+encountered.  (Bison recognizes any nonpositive value as indicating
+end-of-input.)
+
+   Here is the code for the lexical analyzer:
+
+     /* The lexical analyzer returns a double floating point
+        number on the stack and the token NUM, or the numeric code
+        of the character read if not a number.  It skips all blanks
+        and tabs, and returns 0 for end-of-input.  */
+
+     #include <ctype.h>
+
+     int
+     yylex (void)
+     {
+       int c;
+
+       /* Skip white space.  */
+       while ((c = getchar ()) == ' ' || c == '\t')
+         ;
+       /* Process numbers.  */
+       if (c == '.' || isdigit (c))
+         {
+           ungetc (c, stdin);
+           scanf ("%lf", &yylval);
+           return NUM;
+         }
+       /* Return end-of-input.  */
+       if (c == EOF)
+         return 0;
+       /* Return a single char.  */
+       return c;
+     }
+
+
+File: bison.info,  Node: Rpcalc Main,  Next: Rpcalc Error,  Prev: Rpcalc Lexer,  Up: RPN Calc
+
+2.1.4 The Controlling Function
+------------------------------
+
+In keeping with the spirit of this example, the controlling function is
+kept to the bare minimum.  The only requirement is that it call
+`yyparse' to start the process of parsing.
+
+     int
+     main (void)
+     {
+       return yyparse ();
+     }
+
+
+File: bison.info,  Node: Rpcalc Error,  Next: Rpcalc Generate,  Prev: Rpcalc Main,  Up: RPN Calc
+
+2.1.5 The Error Reporting Routine
+---------------------------------
+
+When `yyparse' detects a syntax error, it calls the error reporting
+function `yyerror' to print an error message (usually but not always
+`"syntax error"').  It is up to the programmer to supply `yyerror'
+(*note Parser C-Language Interface: Interface.), so here is the
+definition we will use:
+
+     #include <stdio.h>
+
+     /* Called by yyparse on error.  */
+     void
+     yyerror (char const *s)
+     {
+       fprintf (stderr, "%s\n", s);
+     }
+
+   After `yyerror' returns, the Bison parser may recover from the error
+and continue parsing if the grammar contains a suitable error rule
+(*note Error Recovery::).  Otherwise, `yyparse' returns nonzero.  We
+have not written any error rules in this example, so any invalid input
+will cause the calculator program to exit.  This is not clean behavior
+for a real calculator, but it is adequate for the first example.
+
+
+File: bison.info,  Node: Rpcalc Generate,  Next: Rpcalc Compile,  Prev: Rpcalc Error,  Up: RPN Calc
+
+2.1.6 Running Bison to Make the Parser
+--------------------------------------
+
+Before running Bison to produce a parser, we need to decide how to
+arrange all the source code in one or more source files.  For such a
+simple example, the easiest thing is to put everything in one file.  The
+definitions of `yylex', `yyerror' and `main' go at the end, in the
+epilogue of the file (*note The Overall Layout of a Bison Grammar:
+Grammar Layout.).
+
+   For a large project, you would probably have several source files,
+and use `make' to arrange to recompile them.
+
+   With all the source in a single file, you use the following command
+to convert it into a parser file:
+
+     bison FILE.y
+
+In this example the file was called `rpcalc.y' (for "Reverse Polish
+CALCulator").  Bison produces a file named `FILE.tab.c', removing the
+`.y' from the original file name.  The file output by Bison contains
+the source code for `yyparse'.  The additional functions in the input
+file (`yylex', `yyerror' and `main') are copied verbatim to the output.
+
+
+File: bison.info,  Node: Rpcalc Compile,  Prev: Rpcalc Generate,  Up: RPN Calc
+
+2.1.7 Compiling the Parser File
+-------------------------------
+
+Here is how to compile and run the parser file:
+
+     # List files in current directory.
+     $ ls
+     rpcalc.tab.c  rpcalc.y
+
+     # Compile the Bison parser.
+     # `-lm' tells compiler to search math library for `pow'.
+     $ cc -lm -o rpcalc rpcalc.tab.c
+
+     # List files again.
+     $ ls
+     rpcalc  rpcalc.tab.c  rpcalc.y
+
+   The file `rpcalc' now contains the executable code.  Here is an
+example session using `rpcalc'.
+
+     $ rpcalc
+     4 9 +
+     13
+     3 7 + 3 4 5 *+-
+     -13
+     3 7 + 3 4 5 * + - n              Note the unary minus, `n'
+     13
+     5 6 / 4 n +
+     -3.166666667
+     3 4 ^                            Exponentiation
+     81
+     ^D                               End-of-file indicator
+     $
+
+
+File: bison.info,  Node: Infix Calc,  Next: Simple Error Recovery,  Prev: RPN Calc,  Up: Examples
+
+2.2 Infix Notation Calculator: `calc'
+=====================================
+
+We now modify rpcalc to handle infix operators instead of postfix.
+Infix notation involves the concept of operator precedence and the need
+for parentheses nested to arbitrary depth.  Here is the Bison code for
+`calc.y', an infix desk-top calculator.
+
+     /* Infix notation calculator.  */
+
+     %{
+       #define YYSTYPE double
+       #include <math.h>
+       #include <stdio.h>
+       int yylex (void);
+       void yyerror (char const *);
+     %}
+
+     /* Bison declarations.  */
+     %token NUM
+     %left '-' '+'
+     %left '*' '/'
+     %left NEG     /* negation--unary minus */
+     %right '^'    /* exponentiation */
+
+     %% /* The grammar follows.  */
+     input:    /* empty */
+             | input line
+     ;
+
+     line:     '\n'
+             | exp '\n'  { printf ("\t%.10g\n", $1); }
+     ;
+
+     exp:      NUM                { $$ = $1;         }
+             | exp '+' exp        { $$ = $1 + $3;    }
+             | exp '-' exp        { $$ = $1 - $3;    }
+             | exp '*' exp        { $$ = $1 * $3;    }
+             | exp '/' exp        { $$ = $1 / $3;    }
+             | '-' exp  %prec NEG { $$ = -$2;        }
+             | exp '^' exp        { $$ = pow ($1, $3); }
+             | '(' exp ')'        { $$ = $2;         }
+     ;
+     %%
+
+The functions `yylex', `yyerror' and `main' can be the same as before.
+
+   There are two important new features shown in this code.
+
+   In the second section (Bison declarations), `%left' declares token
+types and says they are left-associative operators.  The declarations
+`%left' and `%right' (right associativity) take the place of `%token'
+which is used to declare a token type name without associativity.
+(These tokens are single-character literals, which ordinarily don't
+need to be declared.  We declare them here to specify the
+associativity.)
+
+   Operator precedence is determined by the line ordering of the
+declarations; the higher the line number of the declaration (lower on
+the page or screen), the higher the precedence.  Hence, exponentiation
+has the highest precedence, unary minus (`NEG') is next, followed by
+`*' and `/', and so on.  *Note Operator Precedence: Precedence.
+
+   The other important new feature is the `%prec' in the grammar
+section for the unary minus operator.  The `%prec' simply instructs
+Bison that the rule `| '-' exp' has the same precedence as `NEG'--in
+this case the next-to-highest.  *Note Context-Dependent Precedence:
+Contextual Precedence.
+
+   Here is a sample run of `calc.y':
+
+     $ calc
+     4 + 4.5 - (34/(8*3+-3))
+     6.880952381
+     -56 + 2
+     -54
+     3 ^ 2
+     9
+
+
+File: bison.info,  Node: Simple Error Recovery,  Next: Location Tracking Calc,  Prev: Infix Calc,  Up: Examples
+
+2.3 Simple Error Recovery
+=========================
+
+Up to this point, this manual has not addressed the issue of "error
+recovery"--how to continue parsing after the parser detects a syntax
+error.  All we have handled is error reporting with `yyerror'.  Recall
+that by default `yyparse' returns after calling `yyerror'.  This means
+that an erroneous input line causes the calculator program to exit.
+Now we show how to rectify this deficiency.
+
+   The Bison language itself includes the reserved word `error', which
+may be included in the grammar rules.  In the example below it has been
+added to one of the alternatives for `line':
+
+     line:     '\n'
+             | exp '\n'   { printf ("\t%.10g\n", $1); }
+             | error '\n' { yyerrok;                  }
+     ;
+
+   This addition to the grammar allows for simple error recovery in the
+event of a syntax error.  If an expression that cannot be evaluated is
+read, the error will be recognized by the third rule for `line', and
+parsing will continue.  (The `yyerror' function is still called upon to
+print its message as well.)  The action executes the statement
+`yyerrok', a macro defined automatically by Bison; its meaning is that
+error recovery is complete (*note Error Recovery::).  Note the
+difference between `yyerrok' and `yyerror'; neither one is a misprint.
+
+   This form of error recovery deals with syntax errors.  There are
+other kinds of errors; for example, division by zero, which raises an
+exception signal that is normally fatal.  A real calculator program
+must handle this signal and use `longjmp' to return to `main' and
+resume parsing input lines; it would also have to discard the rest of
+the current line of input.  We won't discuss this issue further because
+it is not specific to Bison programs.
+
+
+File: bison.info,  Node: Location Tracking Calc,  Next: Multi-function Calc,  Prev: Simple Error Recovery,  Up: Examples
+
+2.4 Location Tracking Calculator: `ltcalc'
+==========================================
+
+This example extends the infix notation calculator with location
+tracking.  This feature will be used to improve the error messages.  For
+the sake of clarity, this example is a simple integer calculator, since
+most of the work needed to use locations will be done in the lexical
+analyzer.
+
+* Menu:
+
+* Ltcalc Declarations::    Bison and C declarations for ltcalc.
+* Ltcalc Rules::           Grammar rules for ltcalc, with explanations.
+* Ltcalc Lexer::           The lexical analyzer.
+
+
+File: bison.info,  Node: Ltcalc Declarations,  Next: Ltcalc Rules,  Up: Location Tracking Calc
+
+2.4.1 Declarations for `ltcalc'
+-------------------------------
+
+The C and Bison declarations for the location tracking calculator are
+the same as the declarations for the infix notation calculator.
+
+     /* Location tracking calculator.  */
+
+     %{
+       #define YYSTYPE int
+       #include <math.h>
+       int yylex (void);
+       void yyerror (char const *);
+     %}
+
+     /* Bison declarations.  */
+     %token NUM
+
+     %left '-' '+'
+     %left '*' '/'
+     %left NEG
+     %right '^'
+
+     %% /* The grammar follows.  */
+
+Note there are no declarations specific to locations.  Defining a data
+type for storing locations is not needed: we will use the type provided
+by default (*note Data Types of Locations: Location Type.), which is a
+four member structure with the following integer fields: `first_line',
+`first_column', `last_line' and `last_column'.  By conventions, and in
+accordance with the GNU Coding Standards and common practice, the line
+and column count both start at 1.
+
+
+File: bison.info,  Node: Ltcalc Rules,  Next: Ltcalc Lexer,  Prev: Ltcalc Declarations,  Up: Location Tracking Calc
+
+2.4.2 Grammar Rules for `ltcalc'
+--------------------------------
+
+Whether handling locations or not has no effect on the syntax of your
+language.  Therefore, grammar rules for this example will be very close
+to those of the previous example: we will only modify them to benefit
+from the new information.
+
+   Here, we will use locations to report divisions by zero, and locate
+the wrong expressions or subexpressions.
+
+     input   : /* empty */
+             | input line
+     ;
+
+     line    : '\n'
+             | exp '\n' { printf ("%d\n", $1); }
+     ;
+
+     exp     : NUM           { $$ = $1; }
+             | exp '+' exp   { $$ = $1 + $3; }
+             | exp '-' exp   { $$ = $1 - $3; }
+             | exp '*' exp   { $$ = $1 * $3; }
+             | exp '/' exp
+                 {
+                   if ($3)
+                     $$ = $1 / $3;
+                   else
+                     {
+                       $$ = 1;
+                       fprintf (stderr, "%d.%d-%d.%d: division by zero",
+                                @3.first_line, @3.first_column,
+                                @3.last_line, @3.last_column);
+                     }
+                 }
+             | '-' exp %prec NEG     { $$ = -$2; }
+             | exp '^' exp           { $$ = pow ($1, $3); }
+             | '(' exp ')'           { $$ = $2; }
+
+   This code shows how to reach locations inside of semantic actions, by
+using the pseudo-variables `@N' for rule components, and the
+pseudo-variable `@$' for groupings.
+
+   We don't need to assign a value to `@$': the output parser does it
+automatically.  By default, before executing the C code of each action,
+`@$' is set to range from the beginning of `@1' to the end of `@N', for
+a rule with N components.  This behavior can be redefined (*note
+Default Action for Locations: Location Default Action.), and for very
+specific rules, `@$' can be computed by hand.
+
+
+File: bison.info,  Node: Ltcalc Lexer,  Prev: Ltcalc Rules,  Up: Location Tracking Calc
+
+2.4.3 The `ltcalc' Lexical Analyzer.
+------------------------------------
+
+Until now, we relied on Bison's defaults to enable location tracking.
+The next step is to rewrite the lexical analyzer, and make it able to
+feed the parser with the token locations, as it already does for
+semantic values.
+
+   To this end, we must take into account every single character of the
+input text, to avoid the computed locations of being fuzzy or wrong:
+
+     int
+     yylex (void)
+     {
+       int c;
+
+       /* Skip white space.  */
+       while ((c = getchar ()) == ' ' || c == '\t')
+         ++yylloc.last_column;
+
+       /* Step.  */
+       yylloc.first_line = yylloc.last_line;
+       yylloc.first_column = yylloc.last_column;
+
+       /* Process numbers.  */
+       if (isdigit (c))
+         {
+           yylval = c - '0';
+           ++yylloc.last_column;
+           while (isdigit (c = getchar ()))
+             {
+               ++yylloc.last_column;
+               yylval = yylval * 10 + c - '0';
+             }
+           ungetc (c, stdin);
+           return NUM;
+         }
+
+       /* Return end-of-input.  */
+       if (c == EOF)
+         return 0;
+
+       /* Return a single char, and update location.  */
+       if (c == '\n')
+         {
+           ++yylloc.last_line;
+           yylloc.last_column = 0;
+         }
+       else
+         ++yylloc.last_column;
+       return c;
+     }
+
+   Basically, the lexical analyzer performs the same processing as
+before: it skips blanks and tabs, and reads numbers or single-character
+tokens.  In addition, it updates `yylloc', the global variable (of type
+`YYLTYPE') containing the token's location.
+
+   Now, each time this function returns a token, the parser has its
+number as well as its semantic value, and its location in the text.
+The last needed change is to initialize `yylloc', for example in the
+controlling function:
+
+     int
+     main (void)
+     {
+       yylloc.first_line = yylloc.last_line = 1;
+       yylloc.first_column = yylloc.last_column = 0;
+       return yyparse ();
+     }
+
+   Remember that computing locations is not a matter of syntax.  Every
+character must be associated to a location update, whether it is in
+valid input, in comments, in literal strings, and so on.
+
+
+File: bison.info,  Node: Multi-function Calc,  Next: Exercises,  Prev: Location Tracking Calc,  Up: Examples
+
+2.5 Multi-Function Calculator: `mfcalc'
+=======================================
+
+Now that the basics of Bison have been discussed, it is time to move on
+to a more advanced problem.  The above calculators provided only five
+functions, `+', `-', `*', `/' and `^'.  It would be nice to have a
+calculator that provides other mathematical functions such as `sin',
+`cos', etc.
+
+   It is easy to add new operators to the infix calculator as long as
+they are only single-character literals.  The lexical analyzer `yylex'
+passes back all nonnumeric characters as tokens, so new grammar rules
+suffice for adding a new operator.  But we want something more
+flexible: built-in functions whose syntax has this form:
+
+     FUNCTION_NAME (ARGUMENT)
+
+At the same time, we will add memory to the calculator, by allowing you
+to create named variables, store values in them, and use them later.
+Here is a sample session with the multi-function calculator:
+
+     $ mfcalc
+     pi = 3.141592653589
+     3.1415926536
+     sin(pi)
+     0.0000000000
+     alpha = beta1 = 2.3
+     2.3000000000
+     alpha
+     2.3000000000
+     ln(alpha)
+     0.8329091229
+     exp(ln(beta1))
+     2.3000000000
+     $
+
+   Note that multiple assignment and nested function calls are
+permitted.
+
+* Menu:
+
+* Mfcalc Declarations::    Bison declarations for multi-function calculator.
+* Mfcalc Rules::           Grammar rules for the calculator.
+* Mfcalc Symbol Table::    Symbol table management subroutines.
+
+
+File: bison.info,  Node: Mfcalc Declarations,  Next: Mfcalc Rules,  Up: Multi-function Calc
+
+2.5.1 Declarations for `mfcalc'
+-------------------------------
+
+Here are the C and Bison declarations for the multi-function calculator.
+
+     %{
+       #include <math.h>  /* For math functions, cos(), sin(), etc.  */
+       #include "calc.h"  /* Contains definition of `symrec'.  */
+       int yylex (void);
+       void yyerror (char const *);
+     %}
+     %union {
+       double    val;   /* For returning numbers.  */
+       symrec  *tptr;   /* For returning symbol-table pointers.  */
+     }
+     %token <val>  NUM        /* Simple double precision number.  */
+     %token <tptr> VAR FNCT   /* Variable and Function.  */
+     %type  <val>  exp
+
+     %right '='
+     %left '-' '+'
+     %left '*' '/'
+     %left NEG     /* negation--unary minus */
+     %right '^'    /* exponentiation */
+     %% /* The grammar follows.  */
+
+   The above grammar introduces only two new features of the Bison
+language.  These features allow semantic values to have various data
+types (*note More Than One Value Type: Multiple Types.).
+
+   The `%union' declaration specifies the entire list of possible types;
+this is instead of defining `YYSTYPE'.  The allowable types are now
+double-floats (for `exp' and `NUM') and pointers to entries in the
+symbol table.  *Note The Collection of Value Types: Union Decl.
+
+   Since values can now have various types, it is necessary to
+associate a type with each grammar symbol whose semantic value is used.
+These symbols are `NUM', `VAR', `FNCT', and `exp'.  Their declarations
+are augmented with information about their data type (placed between
+angle brackets).
+
+   The Bison construct `%type' is used for declaring nonterminal
+symbols, just as `%token' is used for declaring token types.  We have
+not used `%type' before because nonterminal symbols are normally
+declared implicitly by the rules that define them.  But `exp' must be
+declared explicitly so we can specify its value type.  *Note
+Nonterminal Symbols: Type Decl.
+
+
+File: bison.info,  Node: Mfcalc Rules,  Next: Mfcalc Symbol Table,  Prev: Mfcalc Declarations,  Up: Multi-function Calc
+
+2.5.2 Grammar Rules for `mfcalc'
+--------------------------------
+
+Here are the grammar rules for the multi-function calculator.  Most of
+them are copied directly from `calc'; three rules, those which mention
+`VAR' or `FNCT', are new.
+
+     input:   /* empty */
+             | input line
+     ;
+
+     line:
+               '\n'
+             | exp '\n'   { printf ("\t%.10g\n", $1); }
+             | error '\n' { yyerrok;                  }
+     ;
+
+     exp:      NUM                { $$ = $1;                         }
+             | VAR                { $$ = $1->value.var;              }
+             | VAR '=' exp        { $$ = $3; $1->value.var = $3;     }
+             | FNCT '(' exp ')'   { $$ = (*($1->value.fnctptr))($3); }
+             | exp '+' exp        { $$ = $1 + $3;                    }
+             | exp '-' exp        { $$ = $1 - $3;                    }
+             | exp '*' exp        { $$ = $1 * $3;                    }
+             | exp '/' exp        { $$ = $1 / $3;                    }
+             | '-' exp  %prec NEG { $$ = -$2;                        }
+             | exp '^' exp        { $$ = pow ($1, $3);               }
+             | '(' exp ')'        { $$ = $2;                         }
+     ;
+     /* End of grammar.  */
+     %%
+
+
+File: bison.info,  Node: Mfcalc Symbol Table,  Prev: Mfcalc Rules,  Up: Multi-function Calc
+
+2.5.3 The `mfcalc' Symbol Table
+-------------------------------
+
+The multi-function calculator requires a symbol table to keep track of
+the names and meanings of variables and functions.  This doesn't affect
+the grammar rules (except for the actions) or the Bison declarations,
+but it requires some additional C functions for support.
+
+   The symbol table itself consists of a linked list of records.  Its
+definition, which is kept in the header `calc.h', is as follows.  It
+provides for either functions or variables to be placed in the table.
+
+     /* Function type.  */
+     typedef double (*func_t) (double);
+
+     /* Data type for links in the chain of symbols.  */
+     struct symrec
+     {
+       char *name;  /* name of symbol */
+       int type;    /* type of symbol: either VAR or FNCT */
+       union
+       {
+         double var;      /* value of a VAR */
+         func_t fnctptr;  /* value of a FNCT */
+       } value;
+       struct symrec *next;  /* link field */
+     };
+
+     typedef struct symrec symrec;
+
+     /* The symbol table: a chain of `struct symrec'.  */
+     extern symrec *sym_table;
+
+     symrec *putsym (char const *, int);
+     symrec *getsym (char const *);
+
+   The new version of `main' includes a call to `init_table', a
+function that initializes the symbol table.  Here it is, and
+`init_table' as well:
+
+     #include <stdio.h>
+
+     /* Called by yyparse on error.  */
+     void
+     yyerror (char const *s)
+     {
+       printf ("%s\n", s);
+     }
+
+     struct init
+     {
+       char const *fname;
+       double (*fnct) (double);
+     };
+
+     struct init const arith_fncts[] =
+     {
+       "sin",  sin,
+       "cos",  cos,
+       "atan", atan,
+       "ln",   log,
+       "exp",  exp,
+       "sqrt", sqrt,
+       0, 0
+     };
+
+     /* The symbol table: a chain of `struct symrec'.  */
+     symrec *sym_table;
+
+     /* Put arithmetic functions in table.  */
+     void
+     init_table (void)
+     {
+       int i;
+       symrec *ptr;
+       for (i = 0; arith_fncts[i].fname != 0; i++)
+         {
+           ptr = putsym (arith_fncts[i].fname, FNCT);
+           ptr->value.fnctptr = arith_fncts[i].fnct;
+         }
+     }
+
+     int
+     main (void)
+     {
+       init_table ();
+       return yyparse ();
+     }
+
+   By simply editing the initialization list and adding the necessary
+include files, you can add additional functions to the calculator.
+
+   Two important functions allow look-up and installation of symbols in
+the symbol table.  The function `putsym' is passed a name and the type
+(`VAR' or `FNCT') of the object to be installed.  The object is linked
+to the front of the list, and a pointer to the object is returned.  The
+function `getsym' is passed the name of the symbol to look up.  If
+found, a pointer to that symbol is returned; otherwise zero is returned.
+
+     symrec *
+     putsym (char const *sym_name, int sym_type)
+     {
+       symrec *ptr;
+       ptr = (symrec *) malloc (sizeof (symrec));
+       ptr->name = (char *) malloc (strlen (sym_name) + 1);
+       strcpy (ptr->name,sym_name);
+       ptr->type = sym_type;
+       ptr->value.var = 0; /* Set value to 0 even if fctn.  */
+       ptr->next = (struct symrec *)sym_table;
+       sym_table = ptr;
+       return ptr;
+     }
+
+     symrec *
+     getsym (char const *sym_name)
+     {
+       symrec *ptr;
+       for (ptr = sym_table; ptr != (symrec *) 0;
+            ptr = (symrec *)ptr->next)
+         if (strcmp (ptr->name,sym_name) == 0)
+           return ptr;
+       return 0;
+     }
+
+   The function `yylex' must now recognize variables, numeric values,
+and the single-character arithmetic operators.  Strings of alphanumeric
+characters with a leading letter are recognized as either variables or
+functions depending on what the symbol table says about them.
+
+   The string is passed to `getsym' for look up in the symbol table.  If
+the name appears in the table, a pointer to its location and its type
+(`VAR' or `FNCT') is returned to `yyparse'.  If it is not already in
+the table, then it is installed as a `VAR' using `putsym'.  Again, a
+pointer and its type (which must be `VAR') is returned to `yyparse'.
+
+   No change is needed in the handling of numeric values and arithmetic
+operators in `yylex'.
+
+     #include <ctype.h>
+
+     int
+     yylex (void)
+     {
+       int c;
+
+       /* Ignore white space, get first nonwhite character.  */
+       while ((c = getchar ()) == ' ' || c == '\t');
+
+       if (c == EOF)
+         return 0;
+
+       /* Char starts a number => parse the number.         */
+       if (c == '.' || isdigit (c))
+         {
+           ungetc (c, stdin);
+           scanf ("%lf", &yylval.val);
+           return NUM;
+         }
+
+       /* Char starts an identifier => read the name.       */
+       if (isalpha (c))
+         {
+           symrec *s;
+           static char *symbuf = 0;
+           static int length = 0;
+           int i;
+
+           /* Initially make the buffer long enough
+              for a 40-character symbol name.  */
+           if (length == 0)
+             length = 40, symbuf = (char *)malloc (length + 1);
+
+           i = 0;
+           do
+             {
+               /* If buffer is full, make it bigger.        */
+               if (i == length)
+                 {
+                   length *= 2;
+                   symbuf = (char *) realloc (symbuf, length + 1);
+                 }
+               /* Add this character to the buffer.         */
+               symbuf[i++] = c;
+               /* Get another character.                    */
+               c = getchar ();
+             }
+           while (isalnum (c));
+
+           ungetc (c, stdin);
+           symbuf[i] = '\0';
+
+           s = getsym (symbuf);
+           if (s == 0)
+             s = putsym (symbuf, VAR);
+           yylval.tptr = s;
+           return s->type;
+         }
+
+       /* Any other character is a token by itself.        */
+       return c;
+     }
+
+   This program is both powerful and flexible.  You may easily add new
+functions, and it is a simple job to modify this code to install
+predefined variables such as `pi' or `e' as well.
+
+
+File: bison.info,  Node: Exercises,  Prev: Multi-function Calc,  Up: Examples
+
+2.6 Exercises
+=============
+
+  1. Add some new functions from `math.h' to the initialization list.
+
+  2. Add another array that contains constants and their values.  Then
+     modify `init_table' to add these constants to the symbol table.
+     It will be easiest to give the constants type `VAR'.
+
+  3. Make the program report an error if the user refers to an
+     uninitialized variable in any way except to store a value in it.
+
+
+File: bison.info,  Node: Grammar File,  Next: Interface,  Prev: Examples,  Up: Top
+
+3 Bison Grammar Files
+*********************
+
+Bison takes as input a context-free grammar specification and produces a
+C-language function that recognizes correct instances of the grammar.
+
+   The Bison grammar input file conventionally has a name ending in
+`.y'.  *Note Invoking Bison: Invocation.
+
+* Menu:
+
+* Grammar Outline::   Overall layout of the grammar file.
+* Symbols::           Terminal and nonterminal symbols.
+* Rules::             How to write grammar rules.
+* Recursion::         Writing recursive rules.
+* Semantics::         Semantic values and actions.
+* Locations::         Locations and actions.
+* Declarations::      All kinds of Bison declarations are described here.
+* Multiple Parsers::  Putting more than one Bison parser in one program.
+
+
+File: bison.info,  Node: Grammar Outline,  Next: Symbols,  Up: Grammar File
+
+3.1 Outline of a Bison Grammar
+==============================
+
+A Bison grammar file has four main sections, shown here with the
+appropriate delimiters:
+
+     %{
+       PROLOGUE
+     %}
+
+     BISON DECLARATIONS
+
+     %%
+     GRAMMAR RULES
+     %%
+
+     EPILOGUE
+
+   Comments enclosed in `/* ... */' may appear in any of the sections.
+As a GNU extension, `//' introduces a comment that continues until end
+of line.
+
+* Menu:
+
+* Prologue::              Syntax and usage of the prologue.
+* Prologue Alternatives:: Syntax and usage of alternatives to the prologue.
+* Bison Declarations::    Syntax and usage of the Bison declarations section.
+* Grammar Rules::         Syntax and usage of the grammar rules section.
+* Epilogue::              Syntax and usage of the epilogue.
+
+
+File: bison.info,  Node: Prologue,  Next: Prologue Alternatives,  Up: Grammar Outline
+
+3.1.1 The prologue
+------------------
+
+The PROLOGUE section contains macro definitions and declarations of
+functions and variables that are used in the actions in the grammar
+rules.  These are copied to the beginning of the parser file so that
+they precede the definition of `yyparse'.  You can use `#include' to
+get the declarations from a header file.  If you don't need any C
+declarations, you may omit the `%{' and `%}' delimiters that bracket
+this section.
+
+   The PROLOGUE section is terminated by the first occurrence of `%}'
+that is outside a comment, a string literal, or a character constant.
+
+   You may have more than one PROLOGUE section, intermixed with the
+BISON DECLARATIONS.  This allows you to have C and Bison declarations
+that refer to each other.  For example, the `%union' declaration may
+use types defined in a header file, and you may wish to prototype
+functions that take arguments of type `YYSTYPE'.  This can be done with
+two PROLOGUE blocks, one before and one after the `%union' declaration.
+
+     %{
+       #define _GNU_SOURCE
+       #include <stdio.h>
+       #include "ptypes.h"
+     %}
+
+     %union {
+       long int n;
+       tree t;  /* `tree' is defined in `ptypes.h'. */
+     }
+
+     %{
+       static void print_token_value (FILE *, int, YYSTYPE);
+       #define YYPRINT(F, N, L) print_token_value (F, N, L)
+     %}
+
+     ...
+
+   When in doubt, it is usually safer to put prologue code before all
+Bison declarations, rather than after.  For example, any definitions of
+feature test macros like `_GNU_SOURCE' or `_POSIX_C_SOURCE' should
+appear before all Bison declarations, as feature test macros can affect
+the behavior of Bison-generated `#include' directives.
+
+
+File: bison.info,  Node: Prologue Alternatives,  Next: Bison Declarations,  Prev: Prologue,  Up: Grammar Outline
+
+3.1.2 Prologue Alternatives
+---------------------------
+
+(The prologue alternatives described here are experimental.  More user
+feedback will help to determine whether they should become permanent
+features.)
+
+   The functionality of PROLOGUE sections can often be subtle and
+inflexible.  As an alternative, Bison provides a %code directive with
+an explicit qualifier field, which identifies the purpose of the code
+and thus the location(s) where Bison should generate it.  For C/C++,
+the qualifier can be omitted for the default location, or it can be one
+of `requires', `provides', `top'.  *Note %code: Decl Summary.
+
+   Look again at the example of the previous section:
+
+     %{
+       #define _GNU_SOURCE
+       #include <stdio.h>
+       #include "ptypes.h"
+     %}
+
+     %union {
+       long int n;
+       tree t;  /* `tree' is defined in `ptypes.h'. */
+     }
+
+     %{
+       static void print_token_value (FILE *, int, YYSTYPE);
+       #define YYPRINT(F, N, L) print_token_value (F, N, L)
+     %}
+
+     ...
+
+Notice that there are two PROLOGUE sections here, but there's a subtle
+distinction between their functionality.  For example, if you decide to
+override Bison's default definition for `YYLTYPE', in which PROLOGUE
+section should you write your new definition?  You should write it in
+the first since Bison will insert that code into the parser source code
+file _before_ the default `YYLTYPE' definition.  In which PROLOGUE
+section should you prototype an internal function, `trace_token', that
+accepts `YYLTYPE' and `yytokentype' as arguments?  You should prototype
+it in the second since Bison will insert that code _after_ the
+`YYLTYPE' and `yytokentype' definitions.
+
+   This distinction in functionality between the two PROLOGUE sections
+is established by the appearance of the `%union' between them.  This
+behavior raises a few questions.  First, why should the position of a
+`%union' affect definitions related to `YYLTYPE' and `yytokentype'?
+Second, what if there is no `%union'?  In that case, the second kind of
+PROLOGUE section is not available.  This behavior is not intuitive.
+
+   To avoid this subtle `%union' dependency, rewrite the example using a
+`%code top' and an unqualified `%code'.  Let's go ahead and add the new
+`YYLTYPE' definition and the `trace_token' prototype at the same time:
+
+     %code top {
+       #define _GNU_SOURCE
+       #include <stdio.h>
+
+       /* WARNING: The following code really belongs
+        * in a `%code requires'; see below.  */
+
+       #include "ptypes.h"
+       #define YYLTYPE YYLTYPE
+       typedef struct YYLTYPE
+       {
+         int first_line;
+         int first_column;
+         int last_line;
+         int last_column;
+         char *filename;
+       } YYLTYPE;
+     }
+
+     %union {
+       long int n;
+       tree t;  /* `tree' is defined in `ptypes.h'. */
+     }
+
+     %code {
+       static void print_token_value (FILE *, int, YYSTYPE);
+       #define YYPRINT(F, N, L) print_token_value (F, N, L)
+       static void trace_token (enum yytokentype token, YYLTYPE loc);
+     }
+
+     ...
+
+In this way, `%code top' and the unqualified `%code' achieve the same
+functionality as the two kinds of PROLOGUE sections, but it's always
+explicit which kind you intend.  Moreover, both kinds are always
+available even in the absence of `%union'.
+
+   The `%code top' block above logically contains two parts.  The first
+two lines before the warning need to appear near the top of the parser
+source code file.  The first line after the warning is required by
+`YYSTYPE' and thus also needs to appear in the parser source code file.
+However, if you've instructed Bison to generate a parser header file
+(*note %defines: Decl Summary.), you probably want that line to appear
+before the `YYSTYPE' definition in that header file as well.  The
+`YYLTYPE' definition should also appear in the parser header file to
+override the default `YYLTYPE' definition there.
+
+   In other words, in the `%code top' block above, all but the first two
+lines are dependency code required by the `YYSTYPE' and `YYLTYPE'
+definitions.  Thus, they belong in one or more `%code requires':
+
+     %code top {
+       #define _GNU_SOURCE
+       #include <stdio.h>
+     }
+
+     %code requires {
+       #include "ptypes.h"
+     }
+     %union {
+       long int n;
+       tree t;  /* `tree' is defined in `ptypes.h'. */
+     }
+
+     %code requires {
+       #define YYLTYPE YYLTYPE
+       typedef struct YYLTYPE
+       {
+         int first_line;
+         int first_column;
+         int last_line;
+         int last_column;
+         char *filename;
+       } YYLTYPE;
+     }
+
+     %code {
+       static void print_token_value (FILE *, int, YYSTYPE);
+       #define YYPRINT(F, N, L) print_token_value (F, N, L)
+       static void trace_token (enum yytokentype token, YYLTYPE loc);
+     }
+
+     ...
+
+Now Bison will insert `#include "ptypes.h"' and the new `YYLTYPE'
+definition before the Bison-generated `YYSTYPE' and `YYLTYPE'
+definitions in both the parser source code file and the parser header
+file.  (By the same reasoning, `%code requires' would also be the
+appropriate place to write your own definition for `YYSTYPE'.)
+
+   When you are writing dependency code for `YYSTYPE' and `YYLTYPE', you
+should prefer `%code requires' over `%code top' regardless of whether
+you instruct Bison to generate a parser header file.  When you are
+writing code that you need Bison to insert only into the parser source
+code file and that has no special need to appear at the top of that
+file, you should prefer the unqualified `%code' over `%code top'.
+These practices will make the purpose of each block of your code
+explicit to Bison and to other developers reading your grammar file.
+Following these practices, we expect the unqualified `%code' and `%code
+requires' to be the most important of the four PROLOGUE alternatives.
+
+   At some point while developing your parser, you might decide to
+provide `trace_token' to modules that are external to your parser.
+Thus, you might wish for Bison to insert the prototype into both the
+parser header file and the parser source code file.  Since this
+function is not a dependency required by `YYSTYPE' or `YYLTYPE', it
+doesn't make sense to move its prototype to a `%code requires'.  More
+importantly, since it depends upon `YYLTYPE' and `yytokentype', `%code
+requires' is not sufficient.  Instead, move its prototype from the
+unqualified `%code' to a `%code provides':
+
+     %code top {
+       #define _GNU_SOURCE
+       #include <stdio.h>
+     }
+
+     %code requires {
+       #include "ptypes.h"
+     }
+     %union {
+       long int n;
+       tree t;  /* `tree' is defined in `ptypes.h'. */
+     }
+
+     %code requires {
+       #define YYLTYPE YYLTYPE
+       typedef struct YYLTYPE
+       {
+         int first_line;
+         int first_column;
+         int last_line;
+         int last_column;
+         char *filename;
+       } YYLTYPE;
+     }
+
+     %code provides {
+       void trace_token (enum yytokentype token, YYLTYPE loc);
+     }
+
+     %code {
+       static void print_token_value (FILE *, int, YYSTYPE);
+       #define YYPRINT(F, N, L) print_token_value (F, N, L)
+     }
+
+     ...
+
+Bison will insert the `trace_token' prototype into both the parser
+header file and the parser source code file after the definitions for
+`yytokentype', `YYLTYPE', and `YYSTYPE'.
+
+   The above examples are careful to write directives in an order that
+reflects the layout of the generated parser source code and header
+files: `%code top', `%code requires', `%code provides', and then
+`%code'.  While your grammar files may generally be easier to read if
+you also follow this order, Bison does not require it.  Instead, Bison
+lets you choose an organization that makes sense to you.
+
+   You may declare any of these directives multiple times in the
+grammar file.  In that case, Bison concatenates the contained code in
+declaration order.  This is the only way in which the position of one
+of these directives within the grammar file affects its functionality.
+
+   The result of the previous two properties is greater flexibility in
+how you may organize your grammar file.  For example, you may organize
+semantic-type-related directives by semantic type:
+
+     %code requires { #include "type1.h" }
+     %union { type1 field1; }
+     %destructor { type1_free ($$); } <field1>
+     %printer { type1_print ($$); } <field1>
+
+     %code requires { #include "type2.h" }
+     %union { type2 field2; }
+     %destructor { type2_free ($$); } <field2>
+     %printer { type2_print ($$); } <field2>
+
+You could even place each of the above directive groups in the rules
+section of the grammar file next to the set of rules that uses the
+associated semantic type.  (In the rules section, you must terminate
+each of those directives with a semicolon.)  And you don't have to
+worry that some directive (like a `%union') in the definitions section
+is going to adversely affect their functionality in some
+counter-intuitive manner just because it comes first.  Such an
+organization is not possible using PROLOGUE sections.
+
+   This section has been concerned with explaining the advantages of
+the four PROLOGUE alternatives over the original Yacc PROLOGUE.
+However, in most cases when using these directives, you shouldn't need
+to think about all the low-level ordering issues discussed here.
+Instead, you should simply use these directives to label each block of
+your code according to its purpose and let Bison handle the ordering.
+`%code' is the most generic label.  Move code to `%code requires',
+`%code provides', or `%code top' as needed.
+
+
+File: bison.info,  Node: Bison Declarations,  Next: Grammar Rules,  Prev: Prologue Alternatives,  Up: Grammar Outline
+
+3.1.3 The Bison Declarations Section
+------------------------------------
+
+The BISON DECLARATIONS section contains declarations that define
+terminal and nonterminal symbols, specify precedence, and so on.  In
+some simple grammars you may not need any declarations.  *Note Bison
+Declarations: Declarations.
+
+
+File: bison.info,  Node: Grammar Rules,  Next: Epilogue,  Prev: Bison Declarations,  Up: Grammar Outline
+
+3.1.4 The Grammar Rules Section
+-------------------------------
+
+The "grammar rules" section contains one or more Bison grammar rules,
+and nothing else.  *Note Syntax of Grammar Rules: Rules.
+
+   There must always be at least one grammar rule, and the first `%%'
+(which precedes the grammar rules) may never be omitted even if it is
+the first thing in the file.
+
+
+File: bison.info,  Node: Epilogue,  Prev: Grammar Rules,  Up: Grammar Outline
+
+3.1.5 The epilogue
+------------------
+
+The EPILOGUE is copied verbatim to the end of the parser file, just as
+the PROLOGUE is copied to the beginning.  This is the most convenient
+place to put anything that you want to have in the parser file but
+which need not come before the definition of `yyparse'.  For example,
+the definitions of `yylex' and `yyerror' often go here.  Because C
+requires functions to be declared before being used, you often need to
+declare functions like `yylex' and `yyerror' in the Prologue, even if
+you define them in the Epilogue.  *Note Parser C-Language Interface:
+Interface.
+
+   If the last section is empty, you may omit the `%%' that separates it
+from the grammar rules.
+
+   The Bison parser itself contains many macros and identifiers whose
+names start with `yy' or `YY', so it is a good idea to avoid using any
+such names (except those documented in this manual) in the epilogue of
+the grammar file.
+
+
+File: bison.info,  Node: Symbols,  Next: Rules,  Prev: Grammar Outline,  Up: Grammar File
+
+3.2 Symbols, Terminal and Nonterminal
+=====================================
+
+"Symbols" in Bison grammars represent the grammatical classifications
+of the language.
+
+   A "terminal symbol" (also known as a "token type") represents a
+class of syntactically equivalent tokens.  You use the symbol in grammar
+rules to mean that a token in that class is allowed.  The symbol is
+represented in the Bison parser by a numeric code, and the `yylex'
+function returns a token type code to indicate what kind of token has
+been read.  You don't need to know what the code value is; you can use
+the symbol to stand for it.
+
+   A "nonterminal symbol" stands for a class of syntactically
+equivalent groupings.  The symbol name is used in writing grammar rules.
+By convention, it should be all lower case.
+
+   Symbol names can contain letters, digits (not at the beginning),
+underscores and periods.  Periods make sense only in nonterminals.
+
+   There are three ways of writing terminal symbols in the grammar:
+
+   * A "named token type" is written with an identifier, like an
+     identifier in C.  By convention, it should be all upper case.  Each
+     such name must be defined with a Bison declaration such as
+     `%token'.  *Note Token Type Names: Token Decl.
+
+   * A "character token type" (or "literal character token") is written
+     in the grammar using the same syntax used in C for character
+     constants; for example, `'+'' is a character token type.  A
+     character token type doesn't need to be declared unless you need to
+     specify its semantic value data type (*note Data Types of Semantic
+     Values: Value Type.), associativity, or precedence (*note Operator
+     Precedence: Precedence.).
+
+     By convention, a character token type is used only to represent a
+     token that consists of that particular character.  Thus, the token
+     type `'+'' is used to represent the character `+' as a token.
+     Nothing enforces this convention, but if you depart from it, your
+     program will confuse other readers.
+
+     All the usual escape sequences used in character literals in C can
+     be used in Bison as well, but you must not use the null character
+     as a character literal because its numeric code, zero, signifies
+     end-of-input (*note Calling Convention for `yylex': Calling
+     Convention.).  Also, unlike standard C, trigraphs have no special
+     meaning in Bison character literals, nor is backslash-newline
+     allowed.
+
+   * A "literal string token" is written like a C string constant; for
+     example, `"<="' is a literal string token.  A literal string token
+     doesn't need to be declared unless you need to specify its semantic
+     value data type (*note Value Type::), associativity, or precedence
+     (*note Precedence::).
+
+     You can associate the literal string token with a symbolic name as
+     an alias, using the `%token' declaration (*note Token
+     Declarations: Token Decl.).  If you don't do that, the lexical
+     analyzer has to retrieve the token number for the literal string
+     token from the `yytname' table (*note Calling Convention::).
+
+     *Warning*: literal string tokens do not work in Yacc.
+
+     By convention, a literal string token is used only to represent a
+     token that consists of that particular string.  Thus, you should
+     use the token type `"<="' to represent the string `<=' as a token.
+     Bison does not enforce this convention, but if you depart from
+     it, people who read your program will be confused.
+
+     All the escape sequences used in string literals in C can be used
+     in Bison as well, except that you must not use a null character
+     within a string literal.  Also, unlike Standard C, trigraphs have
+     no special meaning in Bison string literals, nor is
+     backslash-newline allowed.  A literal string token must contain
+     two or more characters; for a token containing just one character,
+     use a character token (see above).
+
+   How you choose to write a terminal symbol has no effect on its
+grammatical meaning.  That depends only on where it appears in rules and
+on when the parser function returns that symbol.
+
+   The value returned by `yylex' is always one of the terminal symbols,
+except that a zero or negative value signifies end-of-input.  Whichever
+way you write the token type in the grammar rules, you write it the
+same way in the definition of `yylex'.  The numeric code for a
+character token type is simply the positive numeric code of the
+character, so `yylex' can use the identical value to generate the
+requisite code, though you may need to convert it to `unsigned char' to
+avoid sign-extension on hosts where `char' is signed.  Each named token
+type becomes a C macro in the parser file, so `yylex' can use the name
+to stand for the code.  (This is why periods don't make sense in
+terminal symbols.)  *Note Calling Convention for `yylex': Calling
+Convention.
+
+   If `yylex' is defined in a separate file, you need to arrange for the
+token-type macro definitions to be available there.  Use the `-d'
+option when you run Bison, so that it will write these macro definitions
+into a separate header file `NAME.tab.h' which you can include in the
+other source files that need it.  *Note Invoking Bison: Invocation.
+
+   If you want to write a grammar that is portable to any Standard C
+host, you must use only nonnull character tokens taken from the basic
+execution character set of Standard C.  This set consists of the ten
+digits, the 52 lower- and upper-case English letters, and the
+characters in the following C-language string:
+
+     "\a\b\t\n\v\f\r !\"#%&'()*+,-./:;<=>?[\\]^_{|}~"
+
+   The `yylex' function and Bison must use a consistent character set
+and encoding for character tokens.  For example, if you run Bison in an
+ASCII environment, but then compile and run the resulting program in an
+environment that uses an incompatible character set like EBCDIC, the
+resulting program may not work because the tables generated by Bison
+will assume ASCII numeric values for character tokens.  It is standard
+practice for software distributions to contain C source files that were
+generated by Bison in an ASCII environment, so installers on platforms
+that are incompatible with ASCII must rebuild those files before
+compiling them.
+
+   The symbol `error' is a terminal symbol reserved for error recovery
+(*note Error Recovery::); you shouldn't use it for any other purpose.
+In particular, `yylex' should never return this value.  The default
+value of the error token is 256, unless you explicitly assigned 256 to
+one of your tokens with a `%token' declaration.
+
+
+File: bison.info,  Node: Rules,  Next: Recursion,  Prev: Symbols,  Up: Grammar File
+
+3.3 Syntax of Grammar Rules
+===========================
+
+A Bison grammar rule has the following general form:
+
+     RESULT: COMPONENTS...
+             ;
+
+where RESULT is the nonterminal symbol that this rule describes, and
+COMPONENTS are various terminal and nonterminal symbols that are put
+together by this rule (*note Symbols::).
+
+   For example,
+
+     exp:      exp '+' exp
+             ;
+
+says that two groupings of type `exp', with a `+' token in between, can
+be combined into a larger grouping of type `exp'.
+
+   White space in rules is significant only to separate symbols.  You
+can add extra white space as you wish.
+
+   Scattered among the components can be ACTIONS that determine the
+semantics of the rule.  An action looks like this:
+
+     {C STATEMENTS}
+
+This is an example of "braced code", that is, C code surrounded by
+braces, much like a compound statement in C.  Braced code can contain
+any sequence of C tokens, so long as its braces are balanced.  Bison
+does not check the braced code for correctness directly; it merely
+copies the code to the output file, where the C compiler can check it.
+
+   Within braced code, the balanced-brace count is not affected by
+braces within comments, string literals, or character constants, but it
+is affected by the C digraphs `<%' and `%>' that represent braces.  At
+the top level braced code must be terminated by `}' and not by a
+digraph.  Bison does not look for trigraphs, so if braced code uses
+trigraphs you should ensure that they do not affect the nesting of
+braces or the boundaries of comments, string literals, or character
+constants.
+
+   Usually there is only one action and it follows the components.
+*Note Actions::.
+
+   Multiple rules for the same RESULT can be written separately or can
+be joined with the vertical-bar character `|' as follows:
+
+     RESULT:    RULE1-COMPONENTS...
+             | RULE2-COMPONENTS...
+             ...
+             ;
+
+They are still considered distinct rules even when joined in this way.
+
+   If COMPONENTS in a rule is empty, it means that RESULT can match the
+empty string.  For example, here is how to define a comma-separated
+sequence of zero or more `exp' groupings:
+
+     expseq:   /* empty */
+             | expseq1
+             ;
+
+     expseq1:  exp
+             | expseq1 ',' exp
+             ;
+
+It is customary to write a comment `/* empty */' in each rule with no
+components.
+
+
+File: bison.info,  Node: Recursion,  Next: Semantics,  Prev: Rules,  Up: Grammar File
+
+3.4 Recursive Rules
+===================
+
+A rule is called "recursive" when its RESULT nonterminal appears also
+on its right hand side.  Nearly all Bison grammars need to use
+recursion, because that is the only way to define a sequence of any
+number of a particular thing.  Consider this recursive definition of a
+comma-separated sequence of one or more expressions:
+
+     expseq1:  exp
+             | expseq1 ',' exp
+             ;
+
+Since the recursive use of `expseq1' is the leftmost symbol in the
+right hand side, we call this "left recursion".  By contrast, here the
+same construct is defined using "right recursion":
+
+     expseq1:  exp
+             | exp ',' expseq1
+             ;
+
+Any kind of sequence can be defined using either left recursion or right
+recursion, but you should always use left recursion, because it can
+parse a sequence of any number of elements with bounded stack space.
+Right recursion uses up space on the Bison stack in proportion to the
+number of elements in the sequence, because all the elements must be
+shifted onto the stack before the rule can be applied even once.  *Note
+The Bison Parser Algorithm: Algorithm, for further explanation of this.
+
+   "Indirect" or "mutual" recursion occurs when the result of the rule
+does not appear directly on its right hand side, but does appear in
+rules for other nonterminals which do appear on its right hand side.
+
+   For example:
+
+     expr:     primary
+             | primary '+' primary
+             ;
+
+     primary:  constant
+             | '(' expr ')'
+             ;
+
+defines two mutually-recursive nonterminals, since each refers to the
+other.
+
+
+File: bison.info,  Node: Semantics,  Next: Locations,  Prev: Recursion,  Up: Grammar File
+
+3.5 Defining Language Semantics
+===============================
+
+The grammar rules for a language determine only the syntax.  The
+semantics are determined by the semantic values associated with various
+tokens and groupings, and by the actions taken when various groupings
+are recognized.
+
+   For example, the calculator calculates properly because the value
+associated with each expression is the proper number; it adds properly
+because the action for the grouping `X + Y' is to add the numbers
+associated with X and Y.
+
+* Menu:
+
+* Value Type::        Specifying one data type for all semantic values.
+* Multiple Types::    Specifying several alternative data types.
+* Actions::           An action is the semantic definition of a grammar rule.
+* Action Types::      Specifying data types for actions to operate on.
+* Mid-Rule Actions::  Most actions go at the end of a rule.
+                      This says when, why and how to use the exceptional
+                        action in the middle of a rule.
+
+
+File: bison.info,  Node: Value Type,  Next: Multiple Types,  Up: Semantics
+
+3.5.1 Data Types of Semantic Values
+-----------------------------------
+
+In a simple program it may be sufficient to use the same data type for
+the semantic values of all language constructs.  This was true in the
+RPN and infix calculator examples (*note Reverse Polish Notation
+Calculator: RPN Calc.).
+
+   Bison normally uses the type `int' for semantic values if your
+program uses the same data type for all language constructs.  To
+specify some other type, define `YYSTYPE' as a macro, like this:
+
+     #define YYSTYPE double
+
+`YYSTYPE''s replacement list should be a type name that does not
+contain parentheses or square brackets.  This macro definition must go
+in the prologue of the grammar file (*note Outline of a Bison Grammar:
+Grammar Outline.).
+
+
+File: bison.info,  Node: Multiple Types,  Next: Actions,  Prev: Value Type,  Up: Semantics
+
+3.5.2 More Than One Value Type
+------------------------------
+
+In most programs, you will need different data types for different kinds
+of tokens and groupings.  For example, a numeric constant may need type
+`int' or `long int', while a string constant needs type `char *', and
+an identifier might need a pointer to an entry in the symbol table.
+
+   To use more than one data type for semantic values in one parser,
+Bison requires you to do two things:
+
+   * Specify the entire collection of possible data types, either by
+     using the `%union' Bison declaration (*note The Collection of
+     Value Types: Union Decl.), or by using a `typedef' or a `#define'
+     to define `YYSTYPE' to be a union type whose member names are the
+     type tags.
+
+   * Choose one of those types for each symbol (terminal or
+     nonterminal) for which semantic values are used.  This is done for
+     tokens with the `%token' Bison declaration (*note Token Type
+     Names: Token Decl.)  and for groupings with the `%type' Bison
+     declaration (*note Nonterminal Symbols: Type Decl.).
+
+
+File: bison.info,  Node: Actions,  Next: Action Types,  Prev: Multiple Types,  Up: Semantics
+
+3.5.3 Actions
+-------------
+
+An action accompanies a syntactic rule and contains C code to be
+executed each time an instance of that rule is recognized.  The task of
+most actions is to compute a semantic value for the grouping built by
+the rule from the semantic values associated with tokens or smaller
+groupings.
+
+   An action consists of braced code containing C statements, and can be
+placed at any position in the rule; it is executed at that position.
+Most rules have just one action at the end of the rule, following all
+the components.  Actions in the middle of a rule are tricky and used
+only for special purposes (*note Actions in Mid-Rule: Mid-Rule
+Actions.).
+
+   The C code in an action can refer to the semantic values of the
+components matched by the rule with the construct `$N', which stands for
+the value of the Nth component.  The semantic value for the grouping
+being constructed is `$$'.  Bison translates both of these constructs
+into expressions of the appropriate type when it copies the actions
+into the parser file.  `$$' is translated to a modifiable lvalue, so it
+can be assigned to.
+
+   Here is a typical example:
+
+     exp:    ...
+             | exp '+' exp
+                 { $$ = $1 + $3; }
+
+This rule constructs an `exp' from two smaller `exp' groupings
+connected by a plus-sign token.  In the action, `$1' and `$3' refer to
+the semantic values of the two component `exp' groupings, which are the
+first and third symbols on the right hand side of the rule.  The sum is
+stored into `$$' so that it becomes the semantic value of the
+addition-expression just recognized by the rule.  If there were a
+useful semantic value associated with the `+' token, it could be
+referred to as `$2'.
+
+   Note that the vertical-bar character `|' is really a rule separator,
+and actions are attached to a single rule.  This is a difference with
+tools like Flex, for which `|' stands for either "or", or "the same
+action as that of the next rule".  In the following example, the action
+is triggered only when `b' is found:
+
+     a-or-b: 'a'|'b'   { a_or_b_found = 1; };
+
+   If you don't specify an action for a rule, Bison supplies a default:
+`$$ = $1'.  Thus, the value of the first symbol in the rule becomes the
+value of the whole rule.  Of course, the default action is valid only
+if the two data types match.  There is no meaningful default action for
+an empty rule; every empty rule must have an explicit action unless the
+rule's value does not matter.
+
+   `$N' with N zero or negative is allowed for reference to tokens and
+groupings on the stack _before_ those that match the current rule.
+This is a very risky practice, and to use it reliably you must be
+certain of the context in which the rule is applied.  Here is a case in
+which you can use this reliably:
+
+     foo:      expr bar '+' expr  { ... }
+             | expr bar '-' expr  { ... }
+             ;
+
+     bar:      /* empty */
+             { previous_expr = $0; }
+             ;
+
+   As long as `bar' is used only in the fashion shown here, `$0' always
+refers to the `expr' which precedes `bar' in the definition of `foo'.
+
+   It is also possible to access the semantic value of the lookahead
+token, if any, from a semantic action.  This semantic value is stored
+in `yylval'.  *Note Special Features for Use in Actions: Action
+Features.
+
+
+File: bison.info,  Node: Action Types,  Next: Mid-Rule Actions,  Prev: Actions,  Up: Semantics
+
+3.5.4 Data Types of Values in Actions
+-------------------------------------
+
+If you have chosen a single data type for semantic values, the `$$' and
+`$N' constructs always have that data type.
+
+   If you have used `%union' to specify a variety of data types, then
+you must declare a choice among these types for each terminal or
+nonterminal symbol that can have a semantic value.  Then each time you
+use `$$' or `$N', its data type is determined by which symbol it refers
+to in the rule.  In this example,
+
+     exp:    ...
+             | exp '+' exp
+                 { $$ = $1 + $3; }
+
+`$1' and `$3' refer to instances of `exp', so they all have the data
+type declared for the nonterminal symbol `exp'.  If `$2' were used, it
+would have the data type declared for the terminal symbol `'+'',
+whatever that might be.
+
+   Alternatively, you can specify the data type when you refer to the
+value, by inserting `<TYPE>' after the `$' at the beginning of the
+reference.  For example, if you have defined types as shown here:
+
+     %union {
+       int itype;
+       double dtype;
+     }
+
+then you can write `$<itype>1' to refer to the first subunit of the
+rule as an integer, or `$<dtype>1' to refer to it as a double.
+
+
+File: bison.info,  Node: Mid-Rule Actions,  Prev: Action Types,  Up: Semantics
+
+3.5.5 Actions in Mid-Rule
+-------------------------
+
+Occasionally it is useful to put an action in the middle of a rule.
+These actions are written just like usual end-of-rule actions, but they
+are executed before the parser even recognizes the following components.
+
+   A mid-rule action may refer to the components preceding it using
+`$N', but it may not refer to subsequent components because it is run
+before they are parsed.
+
+   The mid-rule action itself counts as one of the components of the
+rule.  This makes a difference when there is another action later in
+the same rule (and usually there is another at the end): you have to
+count the actions along with the symbols when working out which number
+N to use in `$N'.
+
+   The mid-rule action can also have a semantic value.  The action can
+set its value with an assignment to `$$', and actions later in the rule
+can refer to the value using `$N'.  Since there is no symbol to name
+the action, there is no way to declare a data type for the value in
+advance, so you must use the `$<...>N' construct to specify a data type
+each time you refer to this value.
+
+   There is no way to set the value of the entire rule with a mid-rule
+action, because assignments to `$$' do not have that effect.  The only
+way to set the value for the entire rule is with an ordinary action at
+the end of the rule.
+
+   Here is an example from a hypothetical compiler, handling a `let'
+statement that looks like `let (VARIABLE) STATEMENT' and serves to
+create a variable named VARIABLE temporarily for the duration of
+STATEMENT.  To parse this construct, we must put VARIABLE into the
+symbol table while STATEMENT is parsed, then remove it afterward.  Here
+is how it is done:
+
+     stmt:   LET '(' var ')'
+                     { $<context>$ = push_context ();
+                       declare_variable ($3); }
+             stmt    { $$ = $6;
+                       pop_context ($<context>5); }
+
+As soon as `let (VARIABLE)' has been recognized, the first action is
+run.  It saves a copy of the current semantic context (the list of
+accessible variables) as its semantic value, using alternative
+`context' in the data-type union.  Then it calls `declare_variable' to
+add the new variable to that list.  Once the first action is finished,
+the embedded statement `stmt' can be parsed.  Note that the mid-rule
+action is component number 5, so the `stmt' is component number 6.
+
+   After the embedded statement is parsed, its semantic value becomes
+the value of the entire `let'-statement.  Then the semantic value from
+the earlier action is used to restore the prior list of variables.  This
+removes the temporary `let'-variable from the list so that it won't
+appear to exist while the rest of the program is parsed.
+
+   In the above example, if the parser initiates error recovery (*note
+Error Recovery::) while parsing the tokens in the embedded statement
+`stmt', it might discard the previous semantic context `$<context>5'
+without restoring it.  Thus, `$<context>5' needs a destructor (*note
+Freeing Discarded Symbols: Destructor Decl.).  However, Bison currently
+provides no means to declare a destructor specific to a particular
+mid-rule action's semantic value.
+
+   One solution is to bury the mid-rule action inside a nonterminal
+symbol and to declare a destructor for that symbol:
+
+     %type <context> let
+     %destructor { pop_context ($$); } let
+
+     %%
+
+     stmt:  let stmt
+                    { $$ = $2;
+                      pop_context ($1); }
+            ;
+
+     let:   LET '(' var ')'
+                    { $$ = push_context ();
+                      declare_variable ($3); }
+            ;
+
+Note that the action is now at the end of its rule.  Any mid-rule
+action can be converted to an end-of-rule action in this way, and this
+is what Bison actually does to implement mid-rule actions.
+
+   Taking action before a rule is completely recognized often leads to
+conflicts since the parser must commit to a parse in order to execute
+the action.  For example, the following two rules, without mid-rule
+actions, can coexist in a working parser because the parser can shift
+the open-brace token and look at what follows before deciding whether
+there is a declaration or not:
+
+     compound: '{' declarations statements '}'
+             | '{' statements '}'
+             ;
+
+But when we add a mid-rule action as follows, the rules become
+nonfunctional:
+
+     compound: { prepare_for_local_variables (); }
+               '{' declarations statements '}'
+             | '{' statements '}'
+             ;
+
+Now the parser is forced to decide whether to run the mid-rule action
+when it has read no farther than the open-brace.  In other words, it
+must commit to using one rule or the other, without sufficient
+information to do it correctly.  (The open-brace token is what is called
+the "lookahead" token at this time, since the parser is still deciding
+what to do about it.  *Note Lookahead Tokens: Lookahead.)
+
+   You might think that you could correct the problem by putting
+identical actions into the two rules, like this:
+
+     compound: { prepare_for_local_variables (); }
+               '{' declarations statements '}'
+             | { prepare_for_local_variables (); }
+               '{' statements '}'
+             ;
+
+But this does not help, because Bison does not realize that the two
+actions are identical.  (Bison never tries to understand the C code in
+an action.)
+
+   If the grammar is such that a declaration can be distinguished from a
+statement by the first token (which is true in C), then one solution
+which does work is to put the action after the open-brace, like this:
+
+     compound: '{' { prepare_for_local_variables (); }
+               declarations statements '}'
+             | '{' statements '}'
+             ;
+
+Now the first token of the following declaration or statement, which
+would in any case tell Bison which rule to use, can still do so.
+
+   Another solution is to bury the action inside a nonterminal symbol
+which serves as a subroutine:
+
+     subroutine: /* empty */
+               { prepare_for_local_variables (); }
+             ;
+
+     compound: subroutine
+               '{' declarations statements '}'
+             | subroutine
+               '{' statements '}'
+             ;
+
+Now Bison can execute the action in the rule for `subroutine' without
+deciding which rule for `compound' it will eventually use.
+
+
+File: bison.info,  Node: Locations,  Next: Declarations,  Prev: Semantics,  Up: Grammar File
+
+3.6 Tracking Locations
+======================
+
+Though grammar rules and semantic actions are enough to write a fully
+functional parser, it can be useful to process some additional
+information, especially symbol locations.
+
+   The way locations are handled is defined by providing a data type,
+and actions to take when rules are matched.
+
+* Menu:
+
+* Location Type::               Specifying a data type for locations.
+* Actions and Locations::       Using locations in actions.
+* Location Default Action::     Defining a general way to compute locations.
+
+
+File: bison.info,  Node: Location Type,  Next: Actions and Locations,  Up: Locations
+
+3.6.1 Data Type of Locations
+----------------------------
+
+Defining a data type for locations is much simpler than for semantic
+values, since all tokens and groupings always use the same type.
+
+   You can specify the type of locations by defining a macro called
+`YYLTYPE', just as you can specify the semantic value type by defining
+a `YYSTYPE' macro (*note Value Type::).  When `YYLTYPE' is not defined,
+Bison uses a default structure type with four members:
+
+     typedef struct YYLTYPE
+     {
+       int first_line;
+       int first_column;
+       int last_line;
+       int last_column;
+     } YYLTYPE;
+
+   At the beginning of the parsing, Bison initializes all these fields
+to 1 for `yylloc'.
+
+
+File: bison.info,  Node: Actions and Locations,  Next: Location Default Action,  Prev: Location Type,  Up: Locations
+
+3.6.2 Actions and Locations
+---------------------------
+
+Actions are not only useful for defining language semantics, but also
+for describing the behavior of the output parser with locations.
+
+   The most obvious way for building locations of syntactic groupings
+is very similar to the way semantic values are computed.  In a given
+rule, several constructs can be used to access the locations of the
+elements being matched.  The location of the Nth component of the right
+hand side is `@N', while the location of the left hand side grouping is
+`@$'.
+
+   Here is a basic example using the default data type for locations:
+
+     exp:    ...
+             | exp '/' exp
+                 {
+                   @$.first_column = @1.first_column;
+                   @$.first_line = @1.first_line;
+                   @$.last_column = @3.last_column;
+                   @$.last_line = @3.last_line;
+                   if ($3)
+                     $$ = $1 / $3;
+                   else
+                     {
+                       $$ = 1;
+                       fprintf (stderr,
+                                "Division by zero, l%d,c%d-l%d,c%d",
+                                @3.first_line, @3.first_column,
+                                @3.last_line, @3.last_column);
+                     }
+                 }
+
+   As for semantic values, there is a default action for locations that
+is run each time a rule is matched.  It sets the beginning of `@$' to
+the beginning of the first symbol, and the end of `@$' to the end of the
+last symbol.
+
+   With this default action, the location tracking can be fully
+automatic.  The example above simply rewrites this way:
+
+     exp:    ...
+             | exp '/' exp
+                 {
+                   if ($3)
+                     $$ = $1 / $3;
+                   else
+                     {
+                       $$ = 1;
+                       fprintf (stderr,
+                                "Division by zero, l%d,c%d-l%d,c%d",
+                                @3.first_line, @3.first_column,
+                                @3.last_line, @3.last_column);
+                     }
+                 }
+
+   It is also possible to access the location of the lookahead token,
+if any, from a semantic action.  This location is stored in `yylloc'.
+*Note Special Features for Use in Actions: Action Features.
+
+
+File: bison.info,  Node: Location Default Action,  Prev: Actions and Locations,  Up: Locations
+
+3.6.3 Default Action for Locations
+----------------------------------
+
+Actually, actions are not the best place to compute locations.  Since
+locations are much more general than semantic values, there is room in
+the output parser to redefine the default action to take for each rule.
+The `YYLLOC_DEFAULT' macro is invoked each time a rule is matched,
+before the associated action is run.  It is also invoked while
+processing a syntax error, to compute the error's location.  Before
+reporting an unresolvable syntactic ambiguity, a GLR parser invokes
+`YYLLOC_DEFAULT' recursively to compute the location of that ambiguity.
+
+   Most of the time, this macro is general enough to suppress location
+dedicated code from semantic actions.
+
+   The `YYLLOC_DEFAULT' macro takes three parameters.  The first one is
+the location of the grouping (the result of the computation).  When a
+rule is matched, the second parameter identifies locations of all right
+hand side elements of the rule being matched, and the third parameter
+is the size of the rule's right hand side.  When a GLR parser reports
+an ambiguity, which of multiple candidate right hand sides it passes to
+`YYLLOC_DEFAULT' is undefined.  When processing a syntax error, the
+second parameter identifies locations of the symbols that were
+discarded during error processing, and the third parameter is the
+number of discarded symbols.
+
+   By default, `YYLLOC_DEFAULT' is defined this way:
+
+     # define YYLLOC_DEFAULT(Current, Rhs, N)                                \
+         do                                                                  \
+           if (N)                                                            \
+             {                                                               \
+               (Current).first_line   = YYRHSLOC(Rhs, 1).first_line;         \
+               (Current).first_column = YYRHSLOC(Rhs, 1).first_column;       \
+               (Current).last_line    = YYRHSLOC(Rhs, N).last_line;          \
+               (Current).last_column  = YYRHSLOC(Rhs, N).last_column;        \
+             }                                                               \
+           else                                                              \
+             {                                                               \
+               (Current).first_line   = (Current).last_line   =              \
+                 YYRHSLOC(Rhs, 0).last_line;                                 \
+               (Current).first_column = (Current).last_column =              \
+                 YYRHSLOC(Rhs, 0).last_column;                               \
+             }                                                               \
+         while (0)
+
+   where `YYRHSLOC (rhs, k)' is the location of the Kth symbol in RHS
+when K is positive, and the location of the symbol just before the
+reduction when K and N are both zero.
+
+   When defining `YYLLOC_DEFAULT', you should consider that:
+
+   * All arguments are free of side-effects.  However, only the first
+     one (the result) should be modified by `YYLLOC_DEFAULT'.
+
+   * For consistency with semantic actions, valid indexes within the
+     right hand side range from 1 to N.  When N is zero, only 0 is a
+     valid index, and it refers to the symbol just before the reduction.
+     During error processing N is always positive.
+
+   * Your macro should parenthesize its arguments, if need be, since the
+     actual arguments may not be surrounded by parentheses.  Also, your
+     macro should expand to something that can be used as a single
+     statement when it is followed by a semicolon.
+
+
+File: bison.info,  Node: Declarations,  Next: Multiple Parsers,  Prev: Locations,  Up: Grammar File
+
+3.7 Bison Declarations
+======================
+
+The "Bison declarations" section of a Bison grammar defines the symbols
+used in formulating the grammar and the data types of semantic values.
+*Note Symbols::.
+
+   All token type names (but not single-character literal tokens such as
+`'+'' and `'*'') must be declared.  Nonterminal symbols must be
+declared if you need to specify which data type to use for the semantic
+value (*note More Than One Value Type: Multiple Types.).
+
+   The first rule in the file also specifies the start symbol, by
+default.  If you want some other symbol to be the start symbol, you
+must declare it explicitly (*note Languages and Context-Free Grammars:
+Language and Grammar.).
+
+* Menu:
+
+* Require Decl::      Requiring a Bison version.
+* Token Decl::        Declaring terminal symbols.
+* Precedence Decl::   Declaring terminals with precedence and associativity.
+* Union Decl::        Declaring the set of all semantic value types.
+* Type Decl::         Declaring the choice of type for a nonterminal symbol.
+* Initial Action Decl::  Code run before parsing starts.
+* Destructor Decl::   Declaring how symbols are freed.
+* Expect Decl::       Suppressing warnings about parsing conflicts.
+* Start Decl::        Specifying the start symbol.
+* Pure Decl::         Requesting a reentrant parser.
+* Push Decl::         Requesting a push parser.
+* Decl Summary::      Table of all Bison declarations.
+
+
+File: bison.info,  Node: Require Decl,  Next: Token Decl,  Up: Declarations
+
+3.7.1 Require a Version of Bison
+--------------------------------
+
+You may require the minimum version of Bison to process the grammar.  If
+the requirement is not met, `bison' exits with an error (exit status
+63).
+
+     %require "VERSION"
+
+
+File: bison.info,  Node: Token Decl,  Next: Precedence Decl,  Prev: Require Decl,  Up: Declarations
+
+3.7.2 Token Type Names
+----------------------
+
+The basic way to declare a token type name (terminal symbol) is as
+follows:
+
+     %token NAME
+
+   Bison will convert this into a `#define' directive in the parser, so
+that the function `yylex' (if it is in this file) can use the name NAME
+to stand for this token type's code.
+
+   Alternatively, you can use `%left', `%right', or `%nonassoc' instead
+of `%token', if you wish to specify associativity and precedence.
+*Note Operator Precedence: Precedence Decl.
+
+   You can explicitly specify the numeric code for a token type by
+appending a nonnegative decimal or hexadecimal integer value in the
+field immediately following the token name:
+
+     %token NUM 300
+     %token XNUM 0x12d // a GNU extension
+
+It is generally best, however, to let Bison choose the numeric codes for
+all token types.  Bison will automatically select codes that don't
+conflict with each other or with normal characters.
+
+   In the event that the stack type is a union, you must augment the
+`%token' or other token declaration to include the data type
+alternative delimited by angle-brackets (*note More Than One Value
+Type: Multiple Types.).
+
+   For example:
+
+     %union {              /* define stack type */
+       double val;
+       symrec *tptr;
+     }
+     %token <val> NUM      /* define token NUM and its type */
+
+   You can associate a literal string token with a token type name by
+writing the literal string at the end of a `%token' declaration which
+declares the name.  For example:
+
+     %token arrow "=>"
+
+For example, a grammar for the C language might specify these names with
+equivalent literal string tokens:
+
+     %token  <operator>  OR      "||"
+     %token  <operator>  LE 134  "<="
+     %left  OR  "<="
+
+Once you equate the literal string and the token name, you can use them
+interchangeably in further declarations or the grammar rules.  The
+`yylex' function can use the token name or the literal string to obtain
+the token type code number (*note Calling Convention::).  Syntax error
+messages passed to `yyerror' from the parser will reference the literal
+string instead of the token name.
+
+   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":
+
+     %token END 0 "end of file"
+
+
+File: bison.info,  Node: Precedence Decl,  Next: Union Decl,  Prev: Token Decl,  Up: Declarations
+
+3.7.3 Operator Precedence
+-------------------------
+
+Use the `%left', `%right' or `%nonassoc' declaration to declare a token
+and specify its precedence and associativity, all at once.  These are
+called "precedence declarations".  *Note Operator Precedence:
+Precedence, for general information on operator precedence.
+
+   The syntax of a precedence declaration is nearly the same as that of
+`%token': either
+
+     %left SYMBOLS...
+
+or
+
+     %left <TYPE> SYMBOLS...
+
+   And indeed any of these declarations serves the purposes of `%token'.
+But in addition, they specify the associativity and relative precedence
+for all the SYMBOLS:
+
+   * The associativity of an operator OP determines how repeated uses
+     of the operator nest: whether `X OP Y OP Z' is parsed by grouping
+     X with Y first or by grouping Y with Z first.  `%left' specifies
+     left-associativity (grouping X with Y first) and `%right'
+     specifies right-associativity (grouping Y with Z first).
+     `%nonassoc' specifies no associativity, which means that `X OP Y
+     OP Z' is considered a syntax error.
+
+   * The precedence of an operator determines how it nests with other
+     operators.  All the tokens declared in a single precedence
+     declaration have equal precedence and nest together according to
+     their associativity.  When two tokens declared in different
+     precedence declarations associate, the one declared later has the
+     higher precedence and is grouped first.
+
+   For backward compatibility, there is a confusing difference between
+the argument lists of `%token' and precedence declarations.  Only a
+`%token' can associate a literal string with a token type name.  A
+precedence declaration always interprets a literal string as a
+reference to a separate token.  For example:
+
+     %left  OR "<="         // Does not declare an alias.
+     %left  OR 134 "<=" 135 // Declares 134 for OR and 135 for "<=".
+
+
+File: bison.info,  Node: Union Decl,  Next: Type Decl,  Prev: Precedence Decl,  Up: Declarations
+
+3.7.4 The Collection of Value Types
+-----------------------------------
+
+The `%union' declaration specifies the entire collection of possible
+data types for semantic values.  The keyword `%union' is followed by
+braced code containing the same thing that goes inside a `union' in C.
+
+   For example:
+
+     %union {
+       double val;
+       symrec *tptr;
+     }
+
+This says that the two alternative types are `double' and `symrec *'.
+They are given names `val' and `tptr'; these names are used in the
+`%token' and `%type' declarations to pick one of the types for a
+terminal or nonterminal symbol (*note Nonterminal Symbols: Type Decl.).
+
+   As an extension to POSIX, a tag is allowed after the `union'.  For
+example:
+
+     %union value {
+       double val;
+       symrec *tptr;
+     }
+
+specifies the union tag `value', so the corresponding C type is `union
+value'.  If you do not specify a tag, it defaults to `YYSTYPE'.
+
+   As another extension to POSIX, you may specify multiple `%union'
+declarations; their contents are concatenated.  However, only the first
+`%union' declaration can specify a tag.
+
+   Note that, unlike making a `union' declaration in C, you need not
+write a semicolon after the closing brace.
+
+   Instead of `%union', you can define and use your own union type
+`YYSTYPE' if your grammar contains at least one `<TYPE>' tag.  For
+example, you can put the following into a header file `parser.h':
+
+     union YYSTYPE {
+       double val;
+       symrec *tptr;
+     };
+     typedef union YYSTYPE YYSTYPE;
+
+and then your grammar can use the following instead of `%union':
+
+     %{
+     #include "parser.h"
+     %}
+     %type <val> expr
+     %token <tptr> ID
+
+
+File: bison.info,  Node: Type Decl,  Next: Initial Action Decl,  Prev: Union Decl,  Up: Declarations
+
+3.7.5 Nonterminal Symbols
+-------------------------
+
+When you use `%union' to specify multiple value types, you must declare
+the value type of each nonterminal symbol for which values are used.
+This is done with a `%type' declaration, like this:
+
+     %type <TYPE> NONTERMINAL...
+
+Here NONTERMINAL is the name of a nonterminal symbol, and TYPE is the
+name given in the `%union' to the alternative that you want (*note The
+Collection of Value Types: Union Decl.).  You can give any number of
+nonterminal symbols in the same `%type' declaration, if they have the
+same value type.  Use spaces to separate the symbol names.
+
+   You can also declare the value type of a terminal symbol.  To do
+this, use the same `<TYPE>' construction in a declaration for the
+terminal symbol.  All kinds of token declarations allow `<TYPE>'.
+
+
+File: bison.info,  Node: Initial Action Decl,  Next: Destructor Decl,  Prev: Type Decl,  Up: Declarations
+
+3.7.6 Performing Actions before Parsing
+---------------------------------------
+
+Sometimes your parser needs to perform some initializations before
+parsing.  The `%initial-action' directive allows for such arbitrary
+code.
+
+ -- Directive: %initial-action { CODE }
+     Declare that the braced CODE must be invoked before parsing each
+     time `yyparse' is called.  The CODE may use `$$' and `@$' --
+     initial value and location of the lookahead -- and the
+     `%parse-param'.
+
+   For instance, if your locations use a file name, you may use
+
+     %parse-param { char const *file_name };
+     %initial-action
+     {
+       @$.initialize (file_name);
+     };
+
+
+File: bison.info,  Node: Destructor Decl,  Next: Expect Decl,  Prev: Initial Action Decl,  Up: Declarations
+
+3.7.7 Freeing Discarded Symbols
+-------------------------------
+
+During error recovery (*note Error Recovery::), symbols already pushed
+on the stack and tokens coming from the rest of the file are discarded
+until the parser falls on its feet.  If the parser runs out of memory,
+or if it returns via `YYABORT' or `YYACCEPT', all the symbols on the
+stack must be discarded.  Even if the parser succeeds, it must discard
+the start symbol.
+
+   When discarded symbols convey heap based information, this memory is
+lost.  While this behavior can be tolerable for batch parsers, such as
+in traditional compilers, it is unacceptable for programs like shells or
+protocol implementations that may parse and execute indefinitely.
+
+   The `%destructor' directive defines code that is called when a
+symbol is automatically discarded.
+
+ -- Directive: %destructor { CODE } SYMBOLS
+     Invoke the braced CODE whenever the parser discards one of the
+     SYMBOLS.  Within CODE, `$$' designates the semantic value
+     associated with the discarded symbol, and `@$' designates its
+     location.  The additional parser parameters are also available
+     (*note The Parser Function `yyparse': Parser Function.).
+
+     When a symbol is listed among SYMBOLS, its `%destructor' is called
+     a per-symbol `%destructor'.  You may also define a per-type
+     `%destructor' by listing a semantic type tag among SYMBOLS.  In
+     that case, the parser will invoke this CODE whenever it discards
+     any grammar symbol that has that semantic type tag unless that
+     symbol has its own per-symbol `%destructor'.
+
+     Finally, you can define two different kinds of default
+     `%destructor's.  (These default forms are experimental.  More user
+     feedback will help to determine whether they should become
+     permanent features.)  You can place each of `<*>' and `<>' in the
+     SYMBOLS list of exactly one `%destructor' declaration in your
+     grammar file.  The parser will invoke the CODE associated with one
+     of these whenever it discards any user-defined grammar symbol that
+     has no per-symbol and no per-type `%destructor'.  The parser uses
+     the CODE for `<*>' in the case of such a grammar symbol for which
+     you have formally declared a semantic type tag (`%type' counts as
+     such a declaration, but `$<tag>$' does not).  The parser uses the
+     CODE for `<>' in the case of such a grammar symbol that has no
+     declared semantic type tag.
+
+For example:
+
+     %union { char *string; }
+     %token <string> STRING1
+     %token <string> STRING2
+     %type  <string> string1
+     %type  <string> string2
+     %union { char character; }
+     %token <character> CHR
+     %type  <character> chr
+     %token TAGLESS
+
+     %destructor { } <character>
+     %destructor { free ($$); } <*>
+     %destructor { free ($$); printf ("%d", @$.first_line); } STRING1 string1
+     %destructor { printf ("Discarding tagless symbol.\n"); } <>
+
+guarantees that, when the parser discards any user-defined symbol that
+has a semantic type tag other than `<character>', it passes its
+semantic value to `free' by default.  However, when the parser discards
+a `STRING1' or a `string1', it also prints its line number to `stdout'.
+It performs only the second `%destructor' in this case, so it invokes
+`free' only once.  Finally, the parser merely prints a message whenever
+it discards any symbol, such as `TAGLESS', that has no semantic type
+tag.
+
+   A Bison-generated parser invokes the default `%destructor's only for
+user-defined as opposed to Bison-defined symbols.  For example, the
+parser will not invoke either kind of default `%destructor' for the
+special Bison-defined symbols `$accept', `$undefined', or `$end' (*note
+Bison Symbols: Table of Symbols.), none of which you can reference in
+your grammar.  It also will not invoke either for the `error' token
+(*note error: Table of Symbols.), which is always defined by Bison
+regardless of whether you reference it in your grammar.  However, it
+may invoke one of them for the end token (token 0) if you redefine it
+from `$end' to, for example, `END':
+
+     %token END 0
+
+   Finally, Bison will never invoke a `%destructor' for an unreferenced
+mid-rule semantic value (*note Actions in Mid-Rule: Mid-Rule Actions.).
+That is, Bison does not consider a mid-rule to have a semantic value if
+you do not reference `$$' in the mid-rule's action or `$N' (where N is
+the RHS symbol position of the mid-rule) in any later action in that
+rule.  However, if you do reference either, the Bison-generated parser
+will invoke the `<>' `%destructor' whenever it discards the mid-rule
+symbol.
+
+
+   "Discarded symbols" are the following:
+
+   * stacked symbols popped during the first phase of error recovery,
+
+   * incoming terminals during the second phase of error recovery,
+
+   * the current lookahead and the entire stack (except the current
+     right-hand side symbols) when the parser returns immediately, and
+
+   * the start symbol, when the parser succeeds.
+
+   The parser can "return immediately" because of an explicit call to
+`YYABORT' or `YYACCEPT', or failed error recovery, or memory exhaustion.
+
+   Right-hand side symbols of a rule that explicitly triggers a syntax
+error via `YYERROR' are not discarded automatically.  As a rule of
+thumb, destructors are invoked only when user actions cannot manage the
+memory.
+
+
+File: bison.info,  Node: Expect Decl,  Next: Start Decl,  Prev: Destructor Decl,  Up: Declarations
+
+3.7.8 Suppressing Conflict Warnings
+-----------------------------------
+
+Bison normally warns if there are any conflicts in the grammar (*note
+Shift/Reduce Conflicts: Shift/Reduce.), but most real grammars have
+harmless shift/reduce conflicts which are resolved in a predictable way
+and would be difficult to eliminate.  It is desirable to suppress the
+warning about these conflicts unless the number of conflicts changes.
+You can do this with the `%expect' declaration.
+
+   The declaration looks like this:
+
+     %expect N
+
+   Here N is a decimal integer.  The declaration says there should be N
+shift/reduce conflicts and no reduce/reduce conflicts.  Bison reports
+an error if the number of shift/reduce conflicts differs from N, or if
+there are any reduce/reduce conflicts.
+
+   For normal LALR(1) parsers, reduce/reduce conflicts are more
+serious, and should be eliminated entirely.  Bison will always report
+reduce/reduce conflicts for these parsers.  With GLR parsers, however,
+both kinds of conflicts are routine; otherwise, there would be no need
+to use GLR parsing.  Therefore, it is also possible to specify an
+expected number of reduce/reduce conflicts in GLR parsers, using the
+declaration:
+
+     %expect-rr N
+
+   In general, using `%expect' involves these steps:
+
+   * Compile your grammar without `%expect'.  Use the `-v' option to
+     get a verbose list of where the conflicts occur.  Bison will also
+     print the number of conflicts.
+
+   * Check each of the conflicts to make sure that Bison's default
+     resolution is what you really want.  If not, rewrite the grammar
+     and go back to the beginning.
+
+   * Add an `%expect' declaration, copying the number N from the number
+     which Bison printed.  With GLR parsers, add an `%expect-rr'
+     declaration as well.
+
+   Now Bison will warn you if you introduce an unexpected conflict, but
+will keep silent otherwise.
+
+
+File: bison.info,  Node: Start Decl,  Next: Pure Decl,  Prev: Expect Decl,  Up: Declarations
+
+3.7.9 The Start-Symbol
+----------------------
+
+Bison assumes by default that the start symbol for the grammar is the
+first nonterminal specified in the grammar specification section.  The
+programmer may override this restriction with the `%start' declaration
+as follows:
+
+     %start SYMBOL
+
+
+File: bison.info,  Node: Pure Decl,  Next: Push Decl,  Prev: Start Decl,  Up: Declarations
+
+3.7.10 A Pure (Reentrant) Parser
+--------------------------------
+
+A "reentrant" program is one which does not alter in the course of
+execution; in other words, it consists entirely of "pure" (read-only)
+code.  Reentrancy is important whenever asynchronous execution is
+possible; for example, a nonreentrant program may not be safe to call
+from a signal handler.  In systems with multiple threads of control, a
+nonreentrant program must be called only within interlocks.
+
+   Normally, Bison generates a parser which is not reentrant.  This is
+suitable for most uses, and it permits compatibility with Yacc.  (The
+standard Yacc interfaces are inherently nonreentrant, because they use
+statically allocated variables for communication with `yylex',
+including `yylval' and `yylloc'.)
+
+   Alternatively, you can generate a pure, reentrant parser.  The Bison
+declaration `%define api.pure' says that you want the parser to be
+reentrant.  It looks like this:
+
+     %define api.pure
+
+   The result is that the communication variables `yylval' and `yylloc'
+become local variables in `yyparse', and a different calling convention
+is used for the lexical analyzer function `yylex'.  *Note Calling
+Conventions for Pure Parsers: Pure Calling, for the details of this.
+The variable `yynerrs' becomes local in `yyparse' in pull mode but it
+becomes a member of yypstate in push mode.  (*note The Error Reporting
+Function `yyerror': Error Reporting.).  The convention for calling
+`yyparse' itself is unchanged.
+
+   Whether the parser is pure has nothing to do with the grammar rules.
+You can generate either a pure parser or a nonreentrant parser from any
+valid grammar.
+
+
+File: bison.info,  Node: Push Decl,  Next: Decl Summary,  Prev: Pure Decl,  Up: Declarations
+
+3.7.11 A Push Parser
+--------------------
+
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+
+   A pull parser is called once and it takes control until all its input
+is completely parsed.  A push parser, on the other hand, is called each
+time a new token is made available.
+
+   A push parser is typically useful when the parser is part of a main
+event loop in the client's application.  This is typically a
+requirement of a GUI, when the main event loop needs to be triggered
+within a certain time period.
+
+   Normally, Bison generates a pull parser.  The following Bison
+declaration says that you want the parser to be a push parser (*note
+%define api.push_pull: Decl Summary.):
+
+     %define api.push_pull "push"
+
+   In almost all cases, you want to ensure that your push parser is also
+a pure parser (*note A Pure (Reentrant) Parser: Pure Decl.).  The only
+time you should create an impure push parser is to have backwards
+compatibility with the impure Yacc pull mode interface.  Unless you know
+what you are doing, your declarations should look like this:
+
+     %define api.pure
+     %define api.push_pull "push"
+
+   There is a major notable functional difference between the pure push
+parser and the impure push parser.  It is acceptable for a pure push
+parser to have many parser instances, of the same type of parser, in
+memory at the same time.  An impure push parser should only use one
+parser at a time.
+
+   When a push parser is selected, Bison will generate some new symbols
+in the generated parser.  `yypstate' is a structure that the generated
+parser uses to store the parser's state.  `yypstate_new' is the
+function that will create a new parser instance.  `yypstate_delete'
+will free the resources associated with the corresponding parser
+instance.  Finally, `yypush_parse' is the function that should be
+called whenever a token is available to provide the parser.  A trivial
+example of using a pure push parser would look like this:
+
+     int status;
+     yypstate *ps = yypstate_new ();
+     do {
+       status = yypush_parse (ps, yylex (), NULL);
+     } while (status == YYPUSH_MORE);
+     yypstate_delete (ps);
+
+   If the user decided to use an impure push parser, a few things about
+the generated parser will change.  The `yychar' variable becomes a
+global variable instead of a variable in the `yypush_parse' function.
+For this reason, the signature of the `yypush_parse' function is
+changed to remove the token as a parameter.  A nonreentrant push parser
+example would thus look like this:
+
+     extern int yychar;
+     int status;
+     yypstate *ps = yypstate_new ();
+     do {
+       yychar = yylex ();
+       status = yypush_parse (ps);
+     } while (status == YYPUSH_MORE);
+     yypstate_delete (ps);
+
+   That's it. Notice the next token is put into the global variable
+`yychar' for use by the next invocation of the `yypush_parse' function.
+
+   Bison also supports both the push parser interface along with the
+pull parser interface in the same generated parser.  In order to get
+this functionality, you should replace the `%define api.push_pull
+"push"' declaration with the `%define api.push_pull "both"'
+declaration.  Doing this will create all of the symbols mentioned
+earlier along with the two extra symbols, `yyparse' and `yypull_parse'.
+`yyparse' can be used exactly as it normally would be used.  However,
+the user should note that it is implemented in the generated parser by
+calling `yypull_parse'.  This makes the `yyparse' function that is
+generated with the `%define api.push_pull "both"' declaration slower
+than the normal `yyparse' function.  If the user calls the
+`yypull_parse' function it will parse the rest of the input stream.  It
+is possible to `yypush_parse' tokens to select a subgrammar and then
+`yypull_parse' the rest of the input stream.  If you would like to
+switch back and forth between between parsing styles, you would have to
+write your own `yypull_parse' function that knows when to quit looking
+for input.  An example of using the `yypull_parse' function would look
+like this:
+
+     yypstate *ps = yypstate_new ();
+     yypull_parse (ps); /* Will call the lexer */
+     yypstate_delete (ps);
+
+   Adding the `%define api.pure' declaration does exactly the same
+thing to the generated parser with `%define api.push_pull "both"' as it
+did for `%define api.push_pull "push"'.
+
+
+File: bison.info,  Node: Decl Summary,  Prev: Push Decl,  Up: Declarations
+
+3.7.12 Bison Declaration Summary
+--------------------------------
+
+Here is a summary of the declarations used to define a grammar:
+
+ -- Directive: %union
+     Declare the collection of data types that semantic values may have
+     (*note The Collection of Value Types: Union Decl.).
+
+ -- Directive: %token
+     Declare a terminal symbol (token type name) with no precedence or
+     associativity specified (*note Token Type Names: Token Decl.).
+
+ -- Directive: %right
+     Declare a terminal symbol (token type name) that is
+     right-associative (*note Operator Precedence: Precedence Decl.).
+
+ -- Directive: %left
+     Declare a terminal symbol (token type name) that is
+     left-associative (*note Operator Precedence: Precedence Decl.).
+
+ -- Directive: %nonassoc
+     Declare a terminal symbol (token type name) that is nonassociative
+     (*note Operator Precedence: Precedence Decl.).  Using it in a way
+     that would be associative is a syntax error.
+
+ -- Directive: %type
+     Declare the type of semantic values for a nonterminal symbol
+     (*note Nonterminal Symbols: Type Decl.).
+
+ -- Directive: %start
+     Specify the grammar's start symbol (*note The Start-Symbol: Start
+     Decl.).
+
+ -- Directive: %expect
+     Declare the expected number of shift-reduce conflicts (*note
+     Suppressing Conflict Warnings: Expect Decl.).
+
+
+In order to change the behavior of `bison', use the following
+directives:
+
+ -- Directive: %code {CODE}
+     This is the unqualified form of the `%code' directive.  It inserts
+     CODE verbatim at a language-dependent default location in the
+     output(1).
+
+     For C/C++, the default location is the parser source code file
+     after the usual contents of the parser header file.  Thus, `%code'
+     replaces the traditional Yacc prologue, `%{CODE%}', for most
+     purposes.  For a detailed discussion, see *Note Prologue
+     Alternatives::.
+
+     For Java, the default location is inside the parser class.
+
+     (Like all the Yacc prologue alternatives, this directive is
+     experimental.  More user feedback will help to determine whether
+     it should become a permanent feature.)
+
+ -- Directive: %code QUALIFIER {CODE}
+     This is the qualified form of the `%code' directive.  If you need
+     to specify location-sensitive verbatim CODE that does not belong
+     at the default location selected by the unqualified `%code' form,
+     use this form instead.
+
+     QUALIFIER identifies the purpose of CODE and thus the location(s)
+     where Bison should generate it.  Not all values of QUALIFIER are
+     available for all target languages:
+
+        * requires 
+
+             * Language(s): C, C++
+
+             * Purpose: This is the best place to write dependency code
+               required for `YYSTYPE' and `YYLTYPE'.  In other words,
+               it's the best place to define types referenced in
+               `%union' directives, and it's the best place to override
+               Bison's default `YYSTYPE' and `YYLTYPE' definitions.
+
+             * Location(s): The parser header file and the parser
+               source code file before the Bison-generated `YYSTYPE'
+               and `YYLTYPE' definitions.
+
+        * provides 
+
+             * Language(s): C, C++
+
+             * Purpose: This is the best place to write additional
+               definitions and declarations that should be provided to
+               other modules.
+
+             * Location(s): The parser header file and the parser
+               source code file after the Bison-generated `YYSTYPE',
+               `YYLTYPE', and token definitions.
+
+        * top 
+
+             * Language(s): C, C++
+
+             * Purpose: The unqualified `%code' or `%code requires'
+               should usually be more appropriate than `%code top'.
+               However, occasionally it is necessary to insert code
+               much nearer the top of the parser source code file.  For
+               example:
+
+                    %code top {
+                      #define _GNU_SOURCE
+                      #include <stdio.h>
+                    }
+
+             * Location(s): Near the top of the parser source code file.
+
+        * imports 
+
+             * Language(s): Java
+
+             * Purpose: This is the best place to write Java import
+               directives.
+
+             * Location(s): The parser Java file after any Java package
+               directive and before any class definitions.
+
+     (Like all the Yacc prologue alternatives, this directive is
+     experimental.  More user feedback will help to determine whether
+     it should become a permanent feature.)
+
+     For a detailed discussion of how to use `%code' in place of the
+     traditional Yacc prologue for C/C++, see *Note Prologue
+     Alternatives::.
+
+ -- Directive: %debug
+     In the parser 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.
+
+ -- Directive: %define VARIABLE
+ -- Directive: %define VARIABLE "VALUE"
+     Define a variable to adjust Bison's behavior.  The possible
+     choices for VARIABLE, as well as their meanings, depend on the
+     selected target language and/or the parser skeleton (*note
+     %language: Decl Summary, *note %skeleton: Decl Summary.).
+
+     Bison will warn if a VARIABLE is defined multiple times.
+
+     Omitting `"VALUE"' is always equivalent to specifying it as `""'.
+
+     Some VARIABLEs may be used as Booleans.  In this case, Bison will
+     complain if the variable definition does not meet one of the
+     following four conditions:
+
+       1. `"VALUE"' is `"true"'
+
+       2. `"VALUE"' is omitted (or is `""').  This is equivalent to
+          `"true"'.
+
+       3. `"VALUE"' is `"false"'.
+
+       4. VARIABLE is never defined.  In this case, Bison selects a
+          default value, which may depend on the selected target
+          language and/or parser skeleton.
+
+     Some of the accepted VARIABLEs are:
+
+        * api.pure 
+
+             * Language(s): C
+
+             * Purpose: Request a pure (reentrant) parser program.
+               *Note A Pure (Reentrant) Parser: Pure Decl.
+
+             * Accepted Values: Boolean
+
+             * Default Value: `"false"'
+
+        * api.push_pull 
+
+             * Language(s): C (LALR(1) only)
+
+             * Purpose: Requests a pull parser, a push parser, or both.
+               *Note A Push Parser: Push Decl.  (The current push
+               parsing interface is experimental and may evolve.  More
+               user feedback will help to stabilize it.)
+
+             * Accepted Values: `"pull"', `"push"', `"both"'
+
+             * Default Value: `"pull"'
+
+        * lr.keep_unreachable_states 
+
+             * Language(s): all
+
+             * Purpose: Requests that Bison allow unreachable parser
+               states to remain in the parser tables.  Bison considers
+               a state to be unreachable if there exists no sequence of
+               transitions from the start state to that state.  A state
+               can become unreachable during conflict resolution if
+               Bison disables a shift action leading to it from a
+               predecessor state.  Keeping unreachable states is
+               sometimes useful for analysis purposes, but they are
+               useless in the generated parser.
+
+             * Accepted Values: Boolean
+
+             * Default Value: `"false"'
+
+             * Caveats:
+
+                  * Unreachable states may contain conflicts and may
+                    use rules not used in any other state.  Thus,
+                    keeping unreachable states may induce warnings that
+                    are irrelevant to your parser's behavior, and it
+                    may eliminate warnings that are relevant.  Of
+                    course, the change in warnings may actually be
+                    relevant to a parser table analysis that wants to
+                    keep unreachable states, so this behavior will
+                    likely remain in future Bison releases.
+
+                  * While Bison is able to remove unreachable states,
+                    it is not guaranteed to remove other kinds of
+                    useless states.  Specifically, when Bison disables
+                    reduce actions during conflict resolution, some
+                    goto actions may become useless, and thus some
+                    additional states may become useless.  If Bison
+                    were to compute which goto actions were useless and
+                    then disable those actions, it could identify such
+                    states as unreachable and then remove those states.
+                    However, Bison does not compute which goto actions
+                    are useless.
+
+        * namespace 
+
+             * Languages(s): C++
+
+             * Purpose: Specifies the namespace for the parser class.
+               For example, if you specify:
+
+                    %define namespace "foo::bar"
+
+               Bison uses `foo::bar' verbatim in references such as:
+
+                    foo::bar::parser::semantic_type
+
+               However, to open a namespace, Bison removes any leading
+               `::' and then splits on any remaining occurrences:
+
+                    namespace foo { namespace bar {
+                      class position;
+                      class location;
+                    } }
+
+             * Accepted Values: Any absolute or relative C++ namespace
+               reference without a trailing `"::"'.  For example,
+               `"foo"' or `"::foo::bar"'.
+
+             * Default Value: The value specified by `%name-prefix',
+               which defaults to `yy'.  This usage of `%name-prefix' is
+               for backward compatibility and can be confusing since
+               `%name-prefix' also specifies the textual prefix for the
+               lexical analyzer function.  Thus, if you specify
+               `%name-prefix', it is best to also specify `%define
+               namespace' so that `%name-prefix' _only_ affects the
+               lexical analyzer function.  For example, if you specify:
+
+                    %define namespace "foo"
+                    %name-prefix "bar::"
+
+               The parser namespace is `foo' and `yylex' is referenced
+               as `bar::lex'.
+
+
+ -- Directive: %defines
+     Write a header file containing macro definitions for the token type
+     names defined in the grammar as well as a few other declarations.
+     If the parser output file is named `NAME.c' then this file is
+     named `NAME.h'.
+
+     For C parsers, the output header declares `YYSTYPE' unless
+     `YYSTYPE' is already defined as a macro or you have used a
+     `<TYPE>' tag without using `%union'.  Therefore, if you are using
+     a `%union' (*note More Than One Value Type: Multiple Types.) with
+     components that require other definitions, or if you have defined
+     a `YYSTYPE' macro or type definition (*note Data Types of Semantic
+     Values: Value Type.), you need to arrange for these definitions to
+     be propagated to all modules, e.g., by putting them in a
+     prerequisite header that is included both by your parser and by
+     any other module that needs `YYSTYPE'.
+
+     Unless your parser is pure, the output header declares `yylval' as
+     an external variable.  *Note A Pure (Reentrant) Parser: Pure Decl.
+
+     If you have also used locations, the output header declares
+     `YYLTYPE' and `yylloc' using a protocol similar to that of the
+     `YYSTYPE' macro and `yylval'.  *Note Tracking Locations: Locations.
+
+     This output file is normally essential if you wish to put the
+     definition of `yylex' in a separate source file, because `yylex'
+     typically needs to be able to refer to the above-mentioned
+     declarations and to the token type codes.  *Note Semantic Values
+     of Tokens: Token Values.
+
+     If you have declared `%code requires' or `%code provides', the
+     output header also contains their code.  *Note %code: Decl Summary.
+
+ -- Directive: %defines DEFINES-FILE
+     Same as above, but save in the file DEFINES-FILE.
+
+ -- Directive: %destructor
+     Specify how the parser should reclaim the memory associated to
+     discarded symbols.  *Note Freeing Discarded Symbols: Destructor
+     Decl.
+
+ -- Directive: %file-prefix "PREFIX"
+     Specify a prefix to use for all Bison output file names.  The
+     names are chosen as if the input file were named `PREFIX.y'.
+
+ -- Directive: %language "LANGUAGE"
+     Specify the programming language for the generated parser.
+     Currently supported languages include C, C++, and Java.  LANGUAGE
+     is case-insensitive.
+
+     This directive is experimental and its effect may be modified in
+     future releases.
+
+ -- Directive: %locations
+     Generate the code processing the locations (*note Special Features
+     for Use in Actions: Action Features.).  This mode is enabled as
+     soon as the grammar uses the special `@N' tokens, but if your
+     grammar does not use it, using `%locations' allows for more
+     accurate syntax error messages.
+
+ -- Directive: %name-prefix "PREFIX"
+     Rename the external symbols used in the parser so that they start
+     with PREFIX instead of `yy'.  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.
+     *Note Multiple Parsers in the Same Program: Multiple Parsers.
+
+ -- Directive: %no-lines
+     Don't generate any `#line' preprocessor commands in the parser
+     file.  Ordinarily Bison writes these commands in the parser file
+     so that the C compiler and debuggers will associate errors and
+     object code with your source file (the grammar file).  This
+     directive causes them to associate errors with the parser file,
+     treating it an independent source file in its own right.
+
+ -- Directive: %output "FILE"
+     Specify FILE for the parser file.
+
+ -- Directive: %pure-parser
+     Deprecated version of `%define api.pure' (*note %define: Decl
+     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: %skeleton "FILE"
+     Specify the skeleton to use.
+
+     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 directory of the
+     grammar file.  This is similar to how most shells resolve commands.
+
+ -- Directive: %token-table
+     Generate an array of token names in the parser file.  The name of
+     the array is `yytname'; `yytname[I]' is the name of the token
+     whose internal Bison token code number is I.  The first three
+     elements of `yytname' correspond to the predefined tokens `"$end"',
+     `"error"', and `"$undefined"'; after these come the symbols
+     defined in the grammar file.
+
+     The name in the table includes all the characters needed to
+     represent the token in Bison.  For single-character literals and
+     literal strings, this includes the surrounding quoting characters
+     and any escape sequences.  For example, the Bison single-character
+     literal `'+'' corresponds to a three-character name, represented
+     in C as `"'+'"'; and the Bison two-character literal string `"\\/"'
+     corresponds to a five-character name, represented in C as
+     `"\"\\\\/\""'.
+
+     When you specify `%token-table', Bison also generates macro
+     definitions for macros `YYNTOKENS', `YYNNTS', and `YYNRULES', and
+     `YYNSTATES':
+
+    `YYNTOKENS'
+          The highest token number, plus one.
+
+    `YYNNTS'
+          The number of nonterminal symbols.
+
+    `YYNRULES'
+          The number of grammar rules,
+
+    `YYNSTATES'
+          The number of parser states (*note Parser States::).
+
+ -- Directive: %verbose
+     Write an extra output file containing verbose descriptions of the
+     parser states and what is done for each type of lookahead token in
+     that state.  *Note Understanding Your Parser: Understanding, for
+     more information.
+
+ -- Directive: %yacc
+     Pretend the option `--yacc' was given, i.e., imitate Yacc,
+     including its naming conventions.  *Note Bison Options::, for more.
+
+   ---------- Footnotes ----------
+
+   (1) The default location is actually skeleton-dependent;   writers
+of non-standard skeletons however should choose the default location
+consistently with the behavior of the standard Bison skeletons.
+
+
+File: bison.info,  Node: Multiple Parsers,  Prev: Declarations,  Up: Grammar File
+
+3.8 Multiple Parsers in the Same Program
+========================================
+
+Most programs that use Bison parse only one language and therefore
+contain only one Bison parser.  But what if you want to parse more than
+one language with the same program?  Then you need to avoid a name
+conflict between different definitions of `yyparse', `yylval', and so
+on.
+
+   The easy way to do this is to use the option `-p PREFIX' (*note
+Invoking Bison: Invocation.).  This renames the interface functions and
+variables of the Bison parser to start with PREFIX instead of `yy'.
+You can use this to give each parser distinct names that do not
+conflict.
+
+   The precise list of symbols renamed is `yyparse', `yylex',
+`yyerror', `yynerrs', `yylval', `yylloc', `yychar' and `yydebug'.  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 `-p c', the names become `cparse', `clex', and so
+on.
+
+   *All the other variables and macros associated with Bison are not
+renamed.* These others are not global; there is no conflict if the same
+name is used in different parsers.  For example, `YYSTYPE' is not
+renamed, but defining this in different ways in different parsers causes
+no trouble (*note Data Types of Semantic Values: Value Type.).
+
+   The `-p' option works by adding macro definitions to the beginning
+of the parser source file, defining `yyparse' as `PREFIXparse', and so
+on.  This effectively substitutes one name for the other in the entire
+parser file.
+
+
+File: bison.info,  Node: Interface,  Next: Algorithm,  Prev: Grammar File,  Up: Top
+
+4 Parser C-Language Interface
+*****************************
+
+The Bison parser is actually a C function named `yyparse'.  Here we
+describe the interface conventions of `yyparse' and the other functions
+that it needs to use.
+
+   Keep in mind that the parser uses many C identifiers starting with
+`yy' and `YY' for internal purposes.  If you use such an identifier
+(aside from those in this manual) in an action or in epilogue in the
+grammar file, you are likely to run into trouble.
+
+* Menu:
+
+* Parser Function::         How to call `yyparse' and what it returns.
+* Push Parser Function::    How to call `yypush_parse' and what it returns.
+* Pull Parser Function::    How to call `yypull_parse' and what it returns.
+* Parser Create Function::  How to call `yypstate_new' and what it returns.
+* Parser Delete Function::  How to call `yypstate_delete' and what it returns.
+* Lexical::                 You must supply a function `yylex'
+                              which reads tokens.
+* Error Reporting::         You must supply a function `yyerror'.
+* Action Features::         Special features for use in actions.
+* Internationalization::    How to let the parser speak in the user's
+                              native language.
+
+
+File: bison.info,  Node: Parser Function,  Next: Push Parser Function,  Up: Interface
+
+4.1 The Parser Function `yyparse'
+=================================
+
+You call the function `yyparse' to cause parsing to occur.  This
+function reads tokens, executes actions, and ultimately returns when it
+encounters end-of-input or an unrecoverable syntax error.  You can also
+write an action which directs `yyparse' to return immediately without
+reading further.
+
+ -- Function: int yyparse (void)
+     The value returned by `yyparse' is 0 if parsing was successful
+     (return is due to end-of-input).
+
+     The value is 1 if parsing failed because of invalid input, i.e.,
+     input that contains a syntax error or that causes `YYABORT' to be
+     invoked.
+
+     The value is 2 if parsing failed due to memory exhaustion.
+
+   In an action, you can cause immediate return from `yyparse' by using
+these macros:
+
+ -- Macro: YYACCEPT
+     Return immediately with value 0 (to report success).
+
+ -- Macro: YYABORT
+     Return immediately with value 1 (to report failure).
+
+   If you use a reentrant parser, you can optionally pass additional
+parameter information to it in a reentrant way.  To do so, use the
+declaration `%parse-param':
+
+ -- Directive: %parse-param {ARGUMENT-DECLARATION}
+     Declare that an argument declared by the braced-code
+     ARGUMENT-DECLARATION is an additional `yyparse' argument.  The
+     ARGUMENT-DECLARATION is used when declaring functions or
+     prototypes.  The last identifier in ARGUMENT-DECLARATION must be
+     the argument name.
+
+   Here's an example.  Write this in the parser:
+
+     %parse-param {int *nastiness}
+     %parse-param {int *randomness}
+
+Then call the parser like this:
+
+     {
+       int nastiness, randomness;
+       ...  /* Store proper data in `nastiness' and `randomness'.  */
+       value = yyparse (&nastiness, &randomness);
+       ...
+     }
+
+In the grammar actions, use expressions like this to refer to the data:
+
+     exp: ...    { ...; *randomness += 1; ... }
+
+
+File: bison.info,  Node: Push Parser Function,  Next: Pull Parser Function,  Prev: Parser Function,  Up: Interface
+
+4.2 The Push Parser Function `yypush_parse'
+===========================================
+
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+
+   You call the function `yypush_parse' to parse a single token.  This
+function is available if either the `%define api.push_pull "push"' or
+`%define api.push_pull "both"' declaration is used.  *Note A Push
+Parser: Push Decl.
+
+ -- Function: int yypush_parse (yypstate *yyps)
+     The value returned by `yypush_parse' is the same as for yyparse
+     with the following exception.  `yypush_parse' will return
+     YYPUSH_MORE if more input is required to finish parsing the
+     grammar.
+
+
+File: bison.info,  Node: Pull Parser Function,  Next: Parser Create Function,  Prev: Push Parser Function,  Up: Interface
+
+4.3 The Pull Parser Function `yypull_parse'
+===========================================
+
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+
+   You call the function `yypull_parse' to parse the rest of the input
+stream.  This function is available if the `%define api.push_pull
+"both"' declaration is used.  *Note A Push Parser: Push Decl.
+
+ -- Function: int yypull_parse (yypstate *yyps)
+     The value returned by `yypull_parse' is the same as for `yyparse'.
+
+
+File: bison.info,  Node: Parser Create Function,  Next: Parser Delete Function,  Prev: Pull Parser Function,  Up: Interface
+
+4.4 The Parser Create Function `yystate_new'
+============================================
+
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+
+   You call the function `yypstate_new' to create a new parser instance.
+This function is available if either the `%define api.push_pull "push"'
+or `%define api.push_pull "both"' declaration is used.  *Note A Push
+Parser: Push Decl.
+
+ -- Function: yypstate *yypstate_new (void)
+     The fuction will return a valid parser instance if there was
+     memory available or 0 if no memory was available.  In impure mode,
+     it will also return 0 if a parser instance is currently allocated.
+
+
+File: bison.info,  Node: Parser Delete Function,  Next: Lexical,  Prev: Parser Create Function,  Up: Interface
+
+4.5 The Parser Delete Function `yystate_delete'
+===============================================
+
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+
+   You call the function `yypstate_delete' to delete a parser instance.
+function is available if either the `%define api.push_pull "push"' or
+`%define api.push_pull "both"' declaration is used.  *Note A Push
+Parser: Push Decl.
+
+ -- Function: void yypstate_delete (yypstate *yyps)
+     This function will reclaim the memory associated with a parser
+     instance.  After this call, you should no longer attempt to use
+     the parser instance.
+
+
+File: bison.info,  Node: Lexical,  Next: Error Reporting,  Prev: Parser Delete Function,  Up: Interface
+
+4.6 The Lexical Analyzer Function `yylex'
+=========================================
+
+The "lexical analyzer" function, `yylex', recognizes tokens from the
+input stream and returns them to the parser.  Bison does not create
+this function automatically; you must write it so that `yyparse' can
+call it.  The function is sometimes referred to as a lexical scanner.
+
+   In simple programs, `yylex' is often defined at the end of the Bison
+grammar file.  If `yylex' is defined in a separate source file, you
+need to arrange for the token-type macro definitions to be available
+there.  To do this, use the `-d' option when you run Bison, so that it
+will write these macro definitions into a separate header file
+`NAME.tab.h' which you can include in the other source files that need
+it.  *Note Invoking Bison: Invocation.
+
+* Menu:
+
+* Calling Convention::  How `yyparse' calls `yylex'.
+* Token Values::        How `yylex' must return the semantic value
+                          of the token it has read.
+* Token Locations::     How `yylex' must return the text location
+                          (line number, etc.) of the token, if the
+                          actions want that.
+* Pure Calling::        How the calling convention differs in a pure parser
+                          (*note A Pure (Reentrant) Parser: Pure Decl.).
+
+
+File: bison.info,  Node: Calling Convention,  Next: Token Values,  Up: Lexical
+
+4.6.1 Calling Convention for `yylex'
+------------------------------------
+
+The value that `yylex' returns must be the positive numeric code for
+the type of token it has just found; a zero or negative value signifies
+end-of-input.
+
+   When a token is referred to in the grammar rules by a name, that name
+in the parser file becomes a C macro whose definition is the proper
+numeric code for that token type.  So `yylex' can use the name to
+indicate that type.  *Note Symbols::.
+
+   When a token is referred to in the grammar rules by a character
+literal, the numeric code for that character is also the code for the
+token type.  So `yylex' can simply return that character code, possibly
+converted to `unsigned char' to avoid sign-extension.  The null
+character must not be used this way, because its code is zero and that
+signifies end-of-input.
+
+   Here is an example showing these things:
+
+     int
+     yylex (void)
+     {
+       ...
+       if (c == EOF)    /* Detect end-of-input.  */
+         return 0;
+       ...
+       if (c == '+' || c == '-')
+         return c;      /* Assume token type for `+' is '+'.  */
+       ...
+       return INT;      /* Return the type of the token.  */
+       ...
+     }
+
+This interface has been designed so that the output from the `lex'
+utility can be used without change as the definition of `yylex'.
+
+   If the grammar uses literal string tokens, there are two ways that
+`yylex' can determine the token type codes for them:
+
+   * If the grammar defines symbolic token names as aliases for the
+     literal string tokens, `yylex' can use these symbolic names like
+     all others.  In this case, the use of the literal string tokens in
+     the grammar file has no effect on `yylex'.
+
+   * `yylex' can find the multicharacter token in the `yytname' table.
+     The index of the token in the table is the token type's code.  The
+     name of a multicharacter token is recorded in `yytname' with a
+     double-quote, the token's characters, and another double-quote.
+     The token's characters are escaped as necessary to be suitable as
+     input to Bison.
+
+     Here's code for looking up a multicharacter token in `yytname',
+     assuming that the characters of the token are stored in
+     `token_buffer', and assuming that the token does not contain any
+     characters like `"' that require escaping.
+
+          for (i = 0; i < YYNTOKENS; i++)
+            {
+              if (yytname[i] != 0
+                  && yytname[i][0] == '"'
+                  && ! strncmp (yytname[i] + 1, token_buffer,
+                                strlen (token_buffer))
+                  && yytname[i][strlen (token_buffer) + 1] == '"'
+                  && yytname[i][strlen (token_buffer) + 2] == 0)
+                break;
+            }
+
+     The `yytname' table is generated only if you use the
+     `%token-table' declaration.  *Note Decl Summary::.
+
+
+File: bison.info,  Node: Token Values,  Next: Token Locations,  Prev: Calling Convention,  Up: Lexical
+
+4.6.2 Semantic Values of Tokens
+-------------------------------
+
+In an ordinary (nonreentrant) parser, the semantic value of the token
+must be stored into the global variable `yylval'.  When you are using
+just one data type for semantic values, `yylval' has that type.  Thus,
+if the type is `int' (the default), you might write this in `yylex':
+
+       ...
+       yylval = value;  /* Put value onto Bison stack.  */
+       return INT;      /* Return the type of the token.  */
+       ...
+
+   When you are using multiple data types, `yylval''s type is a union
+made from the `%union' declaration (*note The Collection of Value
+Types: Union Decl.).  So when you store a token's value, you must use
+the proper member of the union.  If the `%union' declaration looks like
+this:
+
+     %union {
+       int intval;
+       double val;
+       symrec *tptr;
+     }
+
+then the code in `yylex' might look like this:
+
+       ...
+       yylval.intval = value; /* Put value onto Bison stack.  */
+       return INT;            /* Return the type of the token.  */
+       ...
+
+
+File: bison.info,  Node: Token Locations,  Next: Pure Calling,  Prev: Token Values,  Up: Lexical
+
+4.6.3 Textual Locations of Tokens
+---------------------------------
+
+If you are using the `@N'-feature (*note Tracking Locations:
+Locations.) in actions to keep track of the textual locations of tokens
+and groupings, then you must provide this information in `yylex'.  The
+function `yyparse' expects to find the textual location of a token just
+parsed in the global variable `yylloc'.  So `yylex' must store the
+proper data in that variable.
+
+   By default, the value of `yylloc' is a structure and you need only
+initialize the members that are going to be used by the actions.  The
+four members are called `first_line', `first_column', `last_line' and
+`last_column'.  Note that the use of this feature makes the parser
+noticeably slower.
+
+   The data type of `yylloc' has the name `YYLTYPE'.
+
+
+File: bison.info,  Node: Pure Calling,  Prev: Token Locations,  Up: Lexical
+
+4.6.4 Calling Conventions for Pure Parsers
+------------------------------------------
+
+When you use the Bison declaration `%define api.pure' to request a
+pure, reentrant parser, the global communication variables `yylval' and
+`yylloc' cannot be used.  (*Note A Pure (Reentrant) Parser: Pure Decl.)
+In such parsers the two global variables are replaced by pointers
+passed as arguments to `yylex'.  You must declare them as shown here,
+and pass the information back by storing it through those pointers.
+
+     int
+     yylex (YYSTYPE *lvalp, YYLTYPE *llocp)
+     {
+       ...
+       *lvalp = value;  /* Put value onto Bison stack.  */
+       return INT;      /* Return the type of the token.  */
+       ...
+     }
+
+   If the grammar file does not use the `@' constructs to refer to
+textual locations, then the type `YYLTYPE' will not be defined.  In
+this case, omit the second argument; `yylex' will be called with only
+one argument.
+
+   If you wish to pass the additional parameter data to `yylex', use
+`%lex-param' just like `%parse-param' (*note Parser Function::).
+
+ -- Directive: lex-param {ARGUMENT-DECLARATION}
+     Declare that the braced-code ARGUMENT-DECLARATION is an additional
+     `yylex' argument declaration.
+
+   For instance:
+
+     %parse-param {int *nastiness}
+     %lex-param   {int *nastiness}
+     %parse-param {int *randomness}
+
+results in the following signature:
+
+     int yylex   (int *nastiness);
+     int yyparse (int *nastiness, int *randomness);
+
+   If `%define api.pure' is added:
+
+     int yylex   (YYSTYPE *lvalp, int *nastiness);
+     int yyparse (int *nastiness, int *randomness);
+
+and finally, if both `%define api.pure' and `%locations' are used:
+
+     int yylex   (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
+     int yyparse (int *nastiness, int *randomness);
+
+
+File: bison.info,  Node: Error Reporting,  Next: Action Features,  Prev: Lexical,  Up: Interface
+
+4.7 The Error Reporting Function `yyerror'
+==========================================
+
+The Bison parser detects a "syntax error" or "parse error" whenever it
+reads a token which cannot satisfy any syntax rule.  An action in the
+grammar can also explicitly proclaim an error, using the macro
+`YYERROR' (*note Special Features for Use in Actions: Action Features.).
+
+   The Bison parser expects to report the error by calling an error
+reporting function named `yyerror', which you must supply.  It is
+called by `yyparse' whenever a syntax error is found, and it receives
+one argument.  For a syntax error, the string is normally
+`"syntax error"'.
+
+   If you invoke the directive `%error-verbose' in the Bison
+declarations section (*note The Bison Declarations Section: Bison
+Declarations.), then Bison provides a more verbose and specific error
+message string instead of just plain `"syntax error"'.
+
+   The parser can detect one other kind of error: memory exhaustion.
+This can happen when the input contains constructions that are very
+deeply nested.  It isn't likely you will encounter this, since the Bison
+parser normally extends its stack automatically up to a very large
+limit.  But if memory is exhausted, `yyparse' calls `yyerror' in the
+usual fashion, except that the argument string is `"memory exhausted"'.
+
+   In some cases diagnostics like `"syntax error"' are translated
+automatically from English to some other language before they are
+passed to `yyerror'.  *Note Internationalization::.
+
+   The following definition suffices in simple programs:
+
+     void
+     yyerror (char const *s)
+     {
+       fprintf (stderr, "%s\n", s);
+     }
+
+   After `yyerror' returns to `yyparse', the latter will attempt error
+recovery if you have written suitable error recovery grammar rules
+(*note Error Recovery::).  If recovery is impossible, `yyparse' will
+immediately return 1.
+
+   Obviously, in location tracking pure parsers, `yyerror' should have
+an access to the current location.  This is indeed the case for the GLR
+parsers, but not for the Yacc parser, for historical reasons.  I.e., if
+`%locations %define api.pure' is passed then the prototypes for
+`yyerror' are:
+
+     void yyerror (char const *msg);                 /* Yacc parsers.  */
+     void yyerror (YYLTYPE *locp, char const *msg);  /* GLR parsers.   */
+
+   If `%parse-param {int *nastiness}' is used, then:
+
+     void yyerror (int *nastiness, char const *msg);  /* Yacc parsers.  */
+     void yyerror (int *nastiness, char const *msg);  /* GLR parsers.   */
+
+   Finally, GLR and Yacc parsers share the same `yyerror' calling
+convention for absolutely pure parsers, i.e., when the calling
+convention of `yylex' _and_ the calling convention of `%define
+api.pure' are pure.  I.e.:
+
+     /* Location tracking.  */
+     %locations
+     /* Pure yylex.  */
+     %define api.pure
+     %lex-param   {int *nastiness}
+     /* Pure yyparse.  */
+     %parse-param {int *nastiness}
+     %parse-param {int *randomness}
+
+results in the following signatures for all the parser kinds:
+
+     int yylex (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
+     int yyparse (int *nastiness, int *randomness);
+     void yyerror (YYLTYPE *locp,
+                   int *nastiness, int *randomness,
+                   char const *msg);
+
+The prototypes are only indications of how the code produced by Bison
+uses `yyerror'.  Bison-generated code always ignores the returned
+value, so `yyerror' can return any type, including `void'.  Also,
+`yyerror' can be a variadic function; that is why the message is always
+passed last.
+
+   Traditionally `yyerror' returns an `int' that is always ignored, but
+this is purely for historical reasons, and `void' is preferable since
+it more accurately describes the return type for `yyerror'.
+
+   The variable `yynerrs' contains the number of syntax errors reported
+so far.  Normally this variable is global; but if you request a pure
+parser (*note A Pure (Reentrant) Parser: Pure Decl.)  then it is a
+local variable which only the actions can access.
+
+
+File: bison.info,  Node: Action Features,  Next: Internationalization,  Prev: Error Reporting,  Up: Interface
+
+4.8 Special Features for Use in Actions
+=======================================
+
+Here is a table of Bison constructs, variables and macros that are
+useful in actions.
+
+ -- Variable: $$
+     Acts like a variable that contains the semantic value for the
+     grouping made by the current rule.  *Note Actions::.
+
+ -- Variable: $N
+     Acts like a variable that contains the semantic value for the Nth
+     component of the current rule.  *Note Actions::.
+
+ -- Variable: $<TYPEALT>$
+     Like `$$' but specifies alternative TYPEALT in the union specified
+     by the `%union' declaration.  *Note Data Types of Values in
+     Actions: Action Types.
+
+ -- Variable: $<TYPEALT>N
+     Like `$N' but specifies alternative TYPEALT in the union specified
+     by the `%union' declaration.  *Note Data Types of Values in
+     Actions: Action Types.
+
+ -- Macro: YYABORT;
+     Return immediately from `yyparse', indicating failure.  *Note The
+     Parser Function `yyparse': Parser Function.
+
+ -- Macro: YYACCEPT;
+     Return immediately from `yyparse', indicating success.  *Note The
+     Parser Function `yyparse': Parser Function.
+
+ -- Macro: YYBACKUP (TOKEN, VALUE);
+     Unshift a token.  This macro is allowed only for rules that reduce
+     a single value, and only when there is no lookahead token.  It is
+     also disallowed in GLR parsers.  It installs a lookahead token
+     with token type TOKEN and semantic value VALUE; then it discards
+     the value that was going to be reduced by this rule.
+
+     If the macro is used when it is not valid, such as when there is a
+     lookahead token already, then it reports a syntax error with a
+     message `cannot back up' and performs ordinary error recovery.
+
+     In either case, the rest of the action is not executed.
+
+ -- Macro: YYEMPTY
+     Value stored in `yychar' when there is no lookahead token.
+
+ -- Macro: YYEOF
+     Value stored in `yychar' when the lookahead is the end of the input
+     stream.
+
+ -- 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::.
+
+ -- Macro: YYRECOVERING
+     The expression `YYRECOVERING ()' yields 1 when the parser is
+     recovering from a syntax error, and 0 otherwise.  *Note Error
+     Recovery::.
+
+ -- Variable: yychar
+     Variable containing either the lookahead token, or `YYEOF' when the
+     lookahead is the end of the input stream, or `YYEMPTY' when no
+     lookahead has been performed so the next token is not yet known.
+     Do not modify `yychar' in a deferred semantic action (*note GLR
+     Semantic Actions::).  *Note Lookahead Tokens: Lookahead.
+
+ -- Macro: yyclearin;
+     Discard the current lookahead token.  This is useful primarily in
+     error rules.  Do not invoke `yyclearin' in a deferred semantic
+     action (*note GLR Semantic Actions::).  *Note Error Recovery::.
+
+ -- Macro: yyerrok;
+     Resume generating error messages immediately for subsequent syntax
+     errors.  This is useful primarily in error rules.  *Note Error
+     Recovery::.
+
+ -- Variable: yylloc
+     Variable containing the lookahead token location when `yychar' is
+     not set to `YYEMPTY' or `YYEOF'.  Do not modify `yylloc' in a
+     deferred semantic action (*note GLR Semantic Actions::).  *Note
+     Actions and Locations: Actions and Locations.
+
+ -- Variable: yylval
+     Variable containing the lookahead token semantic value when
+     `yychar' is not set to `YYEMPTY' or `YYEOF'.  Do not modify
+     `yylval' in a deferred semantic action (*note GLR Semantic
+     Actions::).  *Note Actions: Actions.
+
+ -- Value: @$
+     Acts like a structure variable containing information on the
+     textual location of the grouping made by the current rule.  *Note
+     Tracking Locations: Locations.
+
+
+ -- Value: @N
+     Acts like a structure variable containing information on the
+     textual location of the Nth component of the current rule.  *Note
+     Tracking Locations: Locations.
+
+
+File: bison.info,  Node: Internationalization,  Prev: Action Features,  Up: Interface
+
+4.9 Parser Internationalization
+===============================
+
+A Bison-generated parser can print diagnostics, including error and
+tracing messages.  By default, they appear in English.  However, Bison
+also supports outputting diagnostics in the user's native language.  To
+make this work, the user should set the usual environment variables.
+*Note The User's View: (gettext)Users.  For example, the shell command
+`export LC_ALL=fr_CA.UTF-8' might set the user's locale to French
+Canadian using the UTF-8 encoding.  The exact set of available locales
+depends on the user's installation.
+
+   The maintainer of a package that uses a Bison-generated parser
+enables the internationalization of the parser's output through the
+following steps.  Here we assume a package that uses GNU Autoconf and
+GNU Automake.
+
+  1. Into the directory containing the GNU Autoconf macros used by the
+     package--often called `m4'--copy the `bison-i18n.m4' file
+     installed by Bison under `share/aclocal/bison-i18n.m4' in Bison's
+     installation directory.  For example:
+
+          cp /usr/local/share/aclocal/bison-i18n.m4 m4/bison-i18n.m4
+
+  2. In the top-level `configure.ac', after the `AM_GNU_GETTEXT'
+     invocation, add an invocation of `BISON_I18N'.  This macro is
+     defined in the file `bison-i18n.m4' that you copied earlier.  It
+     causes `configure' to find the value of the `BISON_LOCALEDIR'
+     variable, and it defines the source-language symbol `YYENABLE_NLS'
+     to enable translations in the Bison-generated parser.
+
+  3. In the `main' function of your program, designate the directory
+     containing Bison's runtime message catalog, through a call to
+     `bindtextdomain' with domain name `bison-runtime'.  For example:
+
+          bindtextdomain ("bison-runtime", BISON_LOCALEDIR);
+
+     Typically this appears after any other call `bindtextdomain
+     (PACKAGE, LOCALEDIR)' that your package already has.  Here we rely
+     on `BISON_LOCALEDIR' to be defined as a string through the
+     `Makefile'.
+
+  4. In the `Makefile.am' that controls the compilation of the `main'
+     function, make `BISON_LOCALEDIR' available as a C preprocessor
+     macro, either in `DEFS' or in `AM_CPPFLAGS'.  For example:
+
+          DEFS = @DEFS@ -DBISON_LOCALEDIR='"$(BISON_LOCALEDIR)"'
+
+     or:
+
+          AM_CPPFLAGS = -DBISON_LOCALEDIR='"$(BISON_LOCALEDIR)"'
+
+  5. Finally, invoke the command `autoreconf' to generate the build
+     infrastructure.
+
+
+File: bison.info,  Node: Algorithm,  Next: Error Recovery,  Prev: Interface,  Up: Top
+
+5 The Bison Parser Algorithm
+****************************
+
+As Bison reads tokens, it pushes them onto a stack along with their
+semantic values.  The stack is called the "parser stack".  Pushing a
+token is traditionally called "shifting".
+
+   For example, suppose the infix calculator has read `1 + 5 *', with a
+`3' to come.  The stack will have four elements, one for each token
+that was shifted.
+
+   But the stack does not always have an element for each token read.
+When the last N tokens and groupings shifted match the components of a
+grammar rule, they can be combined according to that rule.  This is
+called "reduction".  Those tokens and groupings are replaced on the
+stack by a single grouping whose symbol is the result (left hand side)
+of that rule.  Running the rule's action is part of the process of
+reduction, because this is what computes the semantic value of the
+resulting grouping.
+
+   For example, if the infix calculator's parser stack contains this:
+
+     1 + 5 * 3
+
+and the next input token is a newline character, then the last three
+elements can be reduced to 15 via the rule:
+
+     expr: expr '*' expr;
+
+Then the stack contains just these three elements:
+
+     1 + 15
+
+At this point, another reduction can be made, resulting in the single
+value 16.  Then the newline token can be shifted.
+
+   The parser tries, by shifts and reductions, to reduce the entire
+input down to a single grouping whose symbol is the grammar's
+start-symbol (*note Languages and Context-Free Grammars: Language and
+Grammar.).
+
+   This kind of parser is known in the literature as a bottom-up parser.
+
+* Menu:
+
+* Lookahead::         Parser looks one token ahead when deciding what to do.
+* Shift/Reduce::      Conflicts: when either shifting or reduction is valid.
+* Precedence::        Operator precedence works by resolving conflicts.
+* Contextual Precedence::  When an operator's precedence depends on context.
+* Parser States::     The parser is a finite-state-machine with stack.
+* Reduce/Reduce::     When two rules are applicable in the same situation.
+* Mystery Conflicts:: Reduce/reduce conflicts that look unjustified.
+* Generalized LR Parsing::  Parsing arbitrary context-free grammars.
+* Memory Management:: What happens when memory is exhausted.  How to avoid it.
+
+
+File: bison.info,  Node: Lookahead,  Next: Shift/Reduce,  Up: Algorithm
+
+5.1 Lookahead Tokens
+====================
+
+The Bison parser does _not_ always reduce immediately as soon as the
+last N tokens and groupings match a rule.  This is because such a
+simple strategy is inadequate to handle most languages.  Instead, when a
+reduction is possible, the parser sometimes "looks ahead" at the next
+token in order to decide what to do.
+
+   When a token is read, it is not immediately shifted; first it
+becomes the "lookahead token", which is not on the stack.  Now the
+parser can perform one or more reductions of tokens and groupings on
+the stack, while the lookahead token remains off to the side.  When no
+more reductions should take place, the lookahead token is shifted onto
+the stack.  This does not mean that all possible reductions have been
+done; depending on the token type of the lookahead token, some rules
+may choose to delay their application.
+
+   Here is a simple case where lookahead is needed.  These three rules
+define expressions which contain binary addition operators and postfix
+unary factorial operators (`!'), and allow parentheses for grouping.
+
+     expr:     term '+' expr
+             | term
+             ;
+
+     term:     '(' expr ')'
+             | term '!'
+             | NUMBER
+             ;
+
+   Suppose that the tokens `1 + 2' have been read and shifted; what
+should be done?  If the following token is `)', then the first three
+tokens must be reduced to form an `expr'.  This is the only valid
+course, because shifting the `)' would produce a sequence of symbols
+`term ')'', and no rule allows this.
+
+   If the following token is `!', then it must be shifted immediately so
+that `2 !' can be reduced to make a `term'.  If instead the parser were
+to reduce before shifting, `1 + 2' would become an `expr'.  It would
+then be impossible to shift the `!' because doing so would produce on
+the stack the sequence of symbols `expr '!''.  No rule allows that
+sequence.
+
+   The lookahead token is stored in the variable `yychar'.  Its
+semantic value and location, if any, are stored in the variables
+`yylval' and `yylloc'.  *Note Special Features for Use in Actions:
+Action Features.
+
+
+File: bison.info,  Node: Shift/Reduce,  Next: Precedence,  Prev: Lookahead,  Up: Algorithm
+
+5.2 Shift/Reduce Conflicts
+==========================
+
+Suppose we are parsing a language which has if-then and if-then-else
+statements, with a pair of rules like this:
+
+     if_stmt:
+               IF expr THEN stmt
+             | IF expr THEN stmt ELSE stmt
+             ;
+
+Here we assume that `IF', `THEN' and `ELSE' are terminal symbols for
+specific keyword tokens.
+
+   When the `ELSE' token is read and becomes the lookahead token, the
+contents of the stack (assuming the input is valid) are just right for
+reduction by the first rule.  But it is also legitimate to shift the
+`ELSE', because that would lead to eventual reduction by the second
+rule.
+
+   This situation, where either a shift or a reduction would be valid,
+is called a "shift/reduce conflict".  Bison is designed to resolve
+these conflicts by choosing to shift, unless otherwise directed by
+operator precedence declarations.  To see the reason for this, let's
+contrast it with the other alternative.
+
+   Since the parser prefers to shift the `ELSE', the result is to attach
+the else-clause to the innermost if-statement, making these two inputs
+equivalent:
+
+     if x then if y then win (); else lose;
+
+     if x then do; if y then win (); else lose; end;
+
+   But if the parser chose to reduce when possible rather than shift,
+the result would be to attach the else-clause to the outermost
+if-statement, making these two inputs equivalent:
+
+     if x then if y then win (); else lose;
+
+     if x then do; if y then win (); end; else lose;
+
+   The conflict exists because the grammar as written is ambiguous:
+either parsing of the simple nested if-statement is legitimate.  The
+established convention is that these ambiguities are resolved by
+attaching the else-clause to the innermost if-statement; this is what
+Bison accomplishes by choosing to shift rather than reduce.  (It would
+ideally be cleaner to write an unambiguous grammar, but that is very
+hard to do in this case.)  This particular ambiguity was first
+encountered in the specifications of Algol 60 and is called the
+"dangling `else'" ambiguity.
+
+   To avoid warnings from Bison about predictable, legitimate
+shift/reduce conflicts, use the `%expect N' declaration.  There will be
+no warning as long as the number of shift/reduce conflicts is exactly N.
+*Note Suppressing Conflict Warnings: Expect Decl.
+
+   The definition of `if_stmt' above is solely to blame for the
+conflict, but the conflict does not actually appear without additional
+rules.  Here is a complete Bison input file that actually manifests the
+conflict:
+
+     %token IF THEN ELSE variable
+     %%
+     stmt:     expr
+             | if_stmt
+             ;
+
+     if_stmt:
+               IF expr THEN stmt
+             | IF expr THEN stmt ELSE stmt
+             ;
+
+     expr:     variable
+             ;
+
+
+File: bison.info,  Node: Precedence,  Next: Contextual Precedence,  Prev: Shift/Reduce,  Up: Algorithm
+
+5.3 Operator Precedence
+=======================
+
+Another situation where shift/reduce conflicts appear is in arithmetic
+expressions.  Here shifting is not always the preferred resolution; the
+Bison declarations for operator precedence allow you to specify when to
+shift and when to reduce.
+
+* Menu:
+
+* Why Precedence::    An example showing why precedence is needed.
+* Using Precedence::  How to specify precedence in Bison grammars.
+* Precedence Examples::  How these features are used in the previous example.
+* How Precedence::    How they work.
+
+
+File: bison.info,  Node: Why Precedence,  Next: Using Precedence,  Up: Precedence
+
+5.3.1 When Precedence is Needed
+-------------------------------
+
+Consider the following ambiguous grammar fragment (ambiguous because the
+input `1 - 2 * 3' can be parsed in two different ways):
+
+     expr:     expr '-' expr
+             | expr '*' expr
+             | expr '<' expr
+             | '(' expr ')'
+             ...
+             ;
+
+Suppose the parser has seen the tokens `1', `-' and `2'; should it
+reduce them via the rule for the subtraction operator?  It depends on
+the next token.  Of course, if the next token is `)', we must reduce;
+shifting is invalid because no single rule can reduce the token
+sequence `- 2 )' or anything starting with that.  But if the next token
+is `*' or `<', we have a choice: either shifting or reduction would
+allow the parse to complete, but with different results.
+
+   To decide which one Bison should do, we must consider the results.
+If the next operator token OP is shifted, then it must be reduced first
+in order to permit another opportunity to reduce the difference.  The
+result is (in effect) `1 - (2 OP 3)'.  On the other hand, if the
+subtraction is reduced before shifting OP, the result is
+`(1 - 2) OP 3'.  Clearly, then, the choice of shift or reduce should
+depend on the relative precedence of the operators `-' and OP: `*'
+should be shifted first, but not `<'.
+
+   What about input such as `1 - 2 - 5'; should this be `(1 - 2) - 5'
+or should it be `1 - (2 - 5)'?  For most operators we prefer the
+former, which is called "left association".  The latter alternative,
+"right association", is desirable for assignment operators.  The choice
+of left or right association is a matter of whether the parser chooses
+to shift or reduce when the stack contains `1 - 2' and the lookahead
+token is `-': shifting makes right-associativity.
+
+
+File: bison.info,  Node: Using Precedence,  Next: Precedence Examples,  Prev: Why Precedence,  Up: Precedence
+
+5.3.2 Specifying Operator Precedence
+------------------------------------
+
+Bison allows you to specify these choices with the operator precedence
+declarations `%left' and `%right'.  Each such declaration contains a
+list of tokens, which are operators whose precedence and associativity
+is being declared.  The `%left' declaration makes all those operators
+left-associative and the `%right' declaration makes them
+right-associative.  A third alternative is `%nonassoc', which declares
+that it is a syntax error to find the same operator twice "in a row".
+
+   The relative precedence of different operators is controlled by the
+order in which they are declared.  The first `%left' or `%right'
+declaration in the file declares the operators whose precedence is
+lowest, the next such declaration declares the operators whose
+precedence is a little higher, and so on.
+
+
+File: bison.info,  Node: Precedence Examples,  Next: How Precedence,  Prev: Using Precedence,  Up: Precedence
+
+5.3.3 Precedence Examples
+-------------------------
+
+In our example, we would want the following declarations:
+
+     %left '<'
+     %left '-'
+     %left '*'
+
+   In a more complete example, which supports other operators as well,
+we would declare them in groups of equal precedence.  For example,
+`'+'' is declared with `'-'':
+
+     %left '<' '>' '=' NE LE GE
+     %left '+' '-'
+     %left '*' '/'
+
+(Here `NE' and so on stand for the operators for "not equal" and so on.
+We assume that these tokens are more than one character long and
+therefore are represented by names, not character literals.)
+
+
+File: bison.info,  Node: How Precedence,  Prev: Precedence Examples,  Up: Precedence
+
+5.3.4 How Precedence Works
+--------------------------
+
+The first effect of the precedence declarations is to assign precedence
+levels to the terminal symbols declared.  The second effect is to assign
+precedence levels to certain rules: each rule gets its precedence from
+the last terminal symbol mentioned in the components.  (You can also
+specify explicitly the precedence of a rule.  *Note Context-Dependent
+Precedence: Contextual Precedence.)
+
+   Finally, the resolution of conflicts works by comparing the
+precedence of the rule being considered with that of the lookahead
+token.  If the token's precedence is higher, the choice is to shift.
+If the rule's precedence is higher, the choice is to reduce.  If they
+have equal precedence, the choice is made based on the associativity of
+that precedence level.  The verbose output file made by `-v' (*note
+Invoking Bison: Invocation.) says how each conflict was resolved.
+
+   Not all rules and not all tokens have precedence.  If either the
+rule or the lookahead token has no precedence, then the default is to
+shift.
+
+
+File: bison.info,  Node: Contextual Precedence,  Next: Parser States,  Prev: Precedence,  Up: Algorithm
+
+5.4 Context-Dependent Precedence
+================================
+
+Often the precedence of an operator depends on the context.  This sounds
+outlandish at first, but it is really very common.  For example, a minus
+sign typically has a very high precedence as a unary operator, and a
+somewhat lower precedence (lower than multiplication) as a binary
+operator.
+
+   The Bison precedence declarations, `%left', `%right' and
+`%nonassoc', can only be used once for a given token; so a token has
+only one precedence declared in this way.  For context-dependent
+precedence, you need to use an additional mechanism: the `%prec'
+modifier for rules.
+
+   The `%prec' modifier declares the precedence of a particular rule by
+specifying a terminal symbol whose precedence should be used for that
+rule.  It's not necessary for that symbol to appear otherwise in the
+rule.  The modifier's syntax is:
+
+     %prec TERMINAL-SYMBOL
+
+and it is written after the components of the rule.  Its effect is to
+assign the rule the precedence of TERMINAL-SYMBOL, overriding the
+precedence that would be deduced for it in the ordinary way.  The
+altered rule precedence then affects how conflicts involving that rule
+are resolved (*note Operator Precedence: Precedence.).
+
+   Here is how `%prec' solves the problem of unary minus.  First,
+declare a precedence for a fictitious terminal symbol named `UMINUS'.
+There are no tokens of this type, but the symbol serves to stand for its
+precedence:
+
+     ...
+     %left '+' '-'
+     %left '*'
+     %left UMINUS
+
+   Now the precedence of `UMINUS' can be used in specific rules:
+
+     exp:    ...
+             | exp '-' exp
+             ...
+             | '-' exp %prec UMINUS
+
+
+File: bison.info,  Node: Parser States,  Next: Reduce/Reduce,  Prev: Contextual Precedence,  Up: Algorithm
+
+5.5 Parser States
+=================
+
+The function `yyparse' is implemented using a finite-state machine.
+The values pushed on the parser stack are not simply token type codes;
+they represent the entire sequence of terminal and nonterminal symbols
+at or near the top of the stack.  The current state collects all the
+information about previous input which is relevant to deciding what to
+do next.
+
+   Each time a lookahead token is read, the current parser state
+together with the type of lookahead token are looked up in a table.
+This table entry can say, "Shift the lookahead token."  In this case,
+it also specifies the new parser state, which is pushed onto the top of
+the parser stack.  Or it can say, "Reduce using rule number N."  This
+means that a certain number of tokens or groupings are taken off the
+top of the stack, and replaced by one grouping.  In other words, that
+number of states are popped from the stack, and one new state is pushed.
+
+   There is one other alternative: the table can say that the lookahead
+token is erroneous in the current state.  This causes error processing
+to begin (*note Error Recovery::).
+
+
+File: bison.info,  Node: Reduce/Reduce,  Next: Mystery Conflicts,  Prev: Parser States,  Up: Algorithm
+
+5.6 Reduce/Reduce Conflicts
+===========================
+
+A reduce/reduce conflict occurs if there are two or more rules that
+apply to the same sequence of input.  This usually indicates a serious
+error in the grammar.
+
+   For example, here is an erroneous attempt to define a sequence of
+zero or more `word' groupings.
+
+     sequence: /* empty */
+                     { printf ("empty sequence\n"); }
+             | maybeword
+             | sequence word
+                     { printf ("added word %s\n", $2); }
+             ;
+
+     maybeword: /* empty */
+                     { printf ("empty maybeword\n"); }
+             | word
+                     { printf ("single word %s\n", $1); }
+             ;
+
+The error is an ambiguity: there is more than one way to parse a single
+`word' into a `sequence'.  It could be reduced to a `maybeword' and
+then into a `sequence' via the second rule.  Alternatively,
+nothing-at-all could be reduced into a `sequence' via the first rule,
+and this could be combined with the `word' using the third rule for
+`sequence'.
+
+   There is also more than one way to reduce nothing-at-all into a
+`sequence'.  This can be done directly via the first rule, or
+indirectly via `maybeword' and then the second rule.
+
+   You might think that this is a distinction without a difference,
+because it does not change whether any particular input is valid or
+not.  But it does affect which actions are run.  One parsing order runs
+the second rule's action; the other runs the first rule's action and
+the third rule's action.  In this example, the output of the program
+changes.
+
+   Bison resolves a reduce/reduce conflict by choosing to use the rule
+that appears first in the grammar, but it is very risky to rely on
+this.  Every reduce/reduce conflict must be studied and usually
+eliminated.  Here is the proper way to define `sequence':
+
+     sequence: /* empty */
+                     { printf ("empty sequence\n"); }
+             | sequence word
+                     { printf ("added word %s\n", $2); }
+             ;
+
+   Here is another common error that yields a reduce/reduce conflict:
+
+     sequence: /* empty */
+             | sequence words
+             | sequence redirects
+             ;
+
+     words:    /* empty */
+             | words word
+             ;
+
+     redirects:/* empty */
+             | redirects redirect
+             ;
+
+The intention here is to define a sequence which can contain either
+`word' or `redirect' groupings.  The individual definitions of
+`sequence', `words' and `redirects' are error-free, but the three
+together make a subtle ambiguity: even an empty input can be parsed in
+infinitely many ways!
+
+   Consider: nothing-at-all could be a `words'.  Or it could be two
+`words' in a row, or three, or any number.  It could equally well be a
+`redirects', or two, or any number.  Or it could be a `words' followed
+by three `redirects' and another `words'.  And so on.
+
+   Here are two ways to correct these rules.  First, to make it a
+single level of sequence:
+
+     sequence: /* empty */
+             | sequence word
+             | sequence redirect
+             ;
+
+   Second, to prevent either a `words' or a `redirects' from being
+empty:
+
+     sequence: /* empty */
+             | sequence words
+             | sequence redirects
+             ;
+
+     words:    word
+             | words word
+             ;
+
+     redirects:redirect
+             | redirects redirect
+             ;
+
+
+File: bison.info,  Node: Mystery Conflicts,  Next: Generalized LR Parsing,  Prev: Reduce/Reduce,  Up: Algorithm
+
+5.7 Mysterious Reduce/Reduce Conflicts
+======================================
+
+Sometimes reduce/reduce conflicts can occur that don't look warranted.
+Here is an example:
+
+     %token ID
+
+     %%
+     def:    param_spec return_spec ','
+             ;
+     param_spec:
+                  type
+             |    name_list ':' type
+             ;
+     return_spec:
+                  type
+             |    name ':' type
+             ;
+     type:        ID
+             ;
+     name:        ID
+             ;
+     name_list:
+                  name
+             |    name ',' name_list
+             ;
+
+   It would seem that this grammar can be parsed with only a single
+token of lookahead: when a `param_spec' is being read, an `ID' is a
+`name' if a comma or colon follows, or a `type' if another `ID'
+follows.  In other words, this grammar is LR(1).
+
+   However, Bison, like most parser generators, cannot actually handle
+all LR(1) grammars.  In this grammar, two contexts, that after an `ID'
+at the beginning of a `param_spec' and likewise at the beginning of a
+`return_spec', are similar enough that Bison assumes they are the same.
+They appear similar because the same set of rules would be active--the
+rule for reducing to a `name' and that for reducing to a `type'.  Bison
+is unable to determine at that stage of processing that the rules would
+require different lookahead tokens in the two contexts, so it makes a
+single parser state for them both.  Combining the two contexts causes a
+conflict later.  In parser terminology, this occurrence means that the
+grammar is not LALR(1).
+
+   In general, it is better to fix deficiencies than to document them.
+But this particular deficiency is intrinsically hard to fix; parser
+generators that can handle LR(1) grammars are hard to write and tend to
+produce parsers that are very large.  In practice, Bison is more useful
+as it is now.
+
+   When the problem arises, you can often fix it by identifying the two
+parser states that are being confused, and adding something to make them
+look distinct.  In the above example, adding one rule to `return_spec'
+as follows makes the problem go away:
+
+     %token BOGUS
+     ...
+     %%
+     ...
+     return_spec:
+                  type
+             |    name ':' type
+             /* This rule is never used.  */
+             |    ID BOGUS
+             ;
+
+   This corrects the problem because it introduces the possibility of an
+additional active rule in the context after the `ID' at the beginning of
+`return_spec'.  This rule is not active in the corresponding context in
+a `param_spec', so the two contexts receive distinct parser states.  As
+long as the token `BOGUS' is never generated by `yylex', the added rule
+cannot alter the way actual input is parsed.
+
+   In this particular example, there is another way to solve the
+problem: rewrite the rule for `return_spec' to use `ID' directly
+instead of via `name'.  This also causes the two confusing contexts to
+have different sets of active rules, because the one for `return_spec'
+activates the altered rule for `return_spec' rather than the one for
+`name'.
+
+     param_spec:
+                  type
+             |    name_list ':' type
+             ;
+     return_spec:
+                  type
+             |    ID ':' type
+             ;
+
+   For a more detailed exposition of LALR(1) parsers and parser
+generators, please see: Frank DeRemer and Thomas Pennello, Efficient
+Computation of LALR(1) Look-Ahead Sets, `ACM Transactions on
+Programming Languages and Systems', Vol. 4, No. 4 (October 1982), pp.
+615-649 `http://doi.acm.org/10.1145/69622.357187'.
+
+
+File: bison.info,  Node: Generalized LR Parsing,  Next: Memory Management,  Prev: Mystery Conflicts,  Up: Algorithm
+
+5.8 Generalized LR (GLR) Parsing
+================================
+
+Bison produces _deterministic_ parsers that choose uniquely when to
+reduce and which reduction to apply based on a summary of the preceding
+input and on one extra token of lookahead.  As a result, normal Bison
+handles a proper subset of the family of context-free languages.
+Ambiguous grammars, since they have strings with more than one possible
+sequence of reductions cannot have deterministic parsers in this sense.
+The same is true of languages that require more than one symbol of
+lookahead, since the parser lacks the information necessary to make a
+decision at the point it must be made in a shift-reduce parser.
+Finally, as previously mentioned (*note Mystery Conflicts::), there are
+languages where Bison's particular choice of how to summarize the input
+seen so far loses necessary information.
+
+   When you use the `%glr-parser' declaration in your grammar file,
+Bison generates a parser that uses a different algorithm, called
+Generalized LR (or GLR).  A Bison GLR parser uses the same basic
+algorithm for parsing as an ordinary Bison parser, but behaves
+differently in cases where there is a shift-reduce conflict that has not
+been resolved by precedence rules (*note Precedence::) or a
+reduce-reduce conflict.  When a GLR parser encounters such a situation,
+it effectively _splits_ into a several parsers, one for each possible
+shift or reduction.  These parsers then proceed as usual, consuming
+tokens in lock-step.  Some of the stacks may encounter other conflicts
+and split further, with the result that instead of a sequence of states,
+a Bison GLR parsing stack is what is in effect a tree of states.
+
+   In effect, each stack represents a guess as to what the proper parse
+is.  Additional input may indicate that a guess was wrong, in which case
+the appropriate stack silently disappears.  Otherwise, the semantics
+actions generated in each stack are saved, rather than being executed
+immediately.  When a stack disappears, its saved semantic actions never
+get executed.  When a reduction causes two stacks to become equivalent,
+their sets of semantic actions are both saved with the state that
+results from the reduction.  We say that two stacks are equivalent when
+they both represent the same sequence of states, and each pair of
+corresponding states represents a grammar symbol that produces the same
+segment of the input token stream.
+
+   Whenever the parser makes a transition from having multiple states
+to having one, it reverts to the normal LALR(1) parsing algorithm,
+after resolving and executing the saved-up actions.  At this
+transition, some of the states on the stack will have semantic values
+that are sets (actually multisets) of possible actions.  The parser
+tries to pick one of the actions by first finding one whose rule has
+the highest dynamic precedence, as set by the `%dprec' declaration.
+Otherwise, if the alternative actions are not ordered by precedence,
+but there the same merging function is declared for both rules by the
+`%merge' declaration, Bison resolves and evaluates both and then calls
+the merge function on the result.  Otherwise, it reports an ambiguity.
+
+   It is possible to use a data structure for the GLR parsing tree that
+permits the processing of any LALR(1) grammar in linear time (in the
+size of the input), any unambiguous (not necessarily LALR(1)) grammar in
+quadratic worst-case time, and any general (possibly ambiguous)
+context-free grammar in cubic worst-case time.  However, Bison currently
+uses a simpler data structure that requires time proportional to the
+length of the input times the maximum number of stacks required for any
+prefix of the input.  Thus, really ambiguous or nondeterministic
+grammars can require exponential time and space to process.  Such badly
+behaving examples, however, are not generally of practical interest.
+Usually, nondeterminism in a grammar is local--the parser is "in doubt"
+only for a few tokens at a time.  Therefore, the current data structure
+should generally be adequate.  On LALR(1) portions of a grammar, in
+particular, it is only slightly slower than with the default Bison
+parser.
+
+   For a more detailed exposition of GLR parsers, please see: 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,
+`http://www.cs.rhul.ac.uk/research/languages/publications/tomita_style_1.ps',
+(2000-12-24).
+
+
+File: bison.info,  Node: Memory Management,  Prev: Generalized LR Parsing,  Up: Algorithm
+
+5.9 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, *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 C LALR(1) parser,
+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 semantical differences between C and C++, the LALR(1)
+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.
+
+
+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:
+
+     stmnts:  /* empty string */
+             | stmnts '\n'
+             | stmnts exp '\n'
+             | stmnts error '\n'
+
+   The fourth rule in this example says that an error followed by a
+newline makes a valid addition to any `stmnts'.
+
+   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 `stmnts', 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 `stmnts', 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
+`stmnts'.)  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:
+
+     stmnt: 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 `stmnt'.  Suppose that instead a spurious semicolon is
+inserted in the middle of a valid `stmnt'.  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 `stmnt'.
+
+   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.
+
+
+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.)
+
+
+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.
+
+
+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 parser 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.
+
+
+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.
+
+
+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.).  Even so, sometimes a detailed description of the automaton
+can help (*note Understanding Your Parser: Understanding.), or tracing
+the execution of the parser can give some insight on why it behaves
+improperly (*note Tracing Your Parser: Tracing.).
+
+* Menu:
+
+* Understanding::     Understanding the structure of your parser.
+* Tracing::           Tracing the execution of your parser.
+
+
+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 output file
+name, and adding `.output' instead.  Therefore, if the input file is
+`foo.y', then the parser 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 and 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 includes details on conflicts that were solved
+thanks to precedence and/or associativity:
+
+     Conflict in state 8 between rule 2 and token '+' resolved as reduce.
+     Conflict in state 8 between rule 2 and token '-' resolved as reduce.
+     Conflict in state 8 between rule 2 and token '*' resolved as shift.
+...
+
+
+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
+
+The next section reports useless tokens, nonterminal 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 reproduces the exact grammar that Bison used:
+
+     Grammar
+
+       Number, Line, Rule
+         0   5 $accept -> exp $end
+         1   5 exp -> exp '+' exp
+         2   6 exp -> exp '-' exp
+         3   7 exp -> exp '*' exp
+         4   8 exp -> exp '/' exp
+         5   9 exp -> 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
+
+     Nonterminals, with rules where they appear
+
+     $accept (8)
+         on left: 0
+     exp (9)
+         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 it set of "items", also known as "pointed rules".  Each item is a
+production rule together with a point (marked by `.') that the input
+cursor.
+
+     state 0
+
+         $accept  ->  . exp $   (rule 0)
+
+         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 on 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 all
+the items, include those that can be derived:
+
+     state 0
+
+         $accept  ->  . exp $   (rule 0)
+         exp  ->  . exp '+' exp   (rule 1)
+         exp  ->  . exp '-' exp   (rule 2)
+         exp  ->  . exp '*' exp   (rule 3)
+         exp  ->  . exp '/' exp   (rule 4)
+         exp  ->  . NUM   (rule 5)
+
+         NUM         shift, and go to state 1
+
+         exp         go to state 2
+
+In the state 1...
+
+     state 1
+
+         exp  ->  NUM .   (rule 5)
+
+         $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
+
+         $accept  ->  exp . $   (rule 0)
+         exp  ->  exp . '+' exp   (rule 1)
+         exp  ->  exp . '-' exp   (rule 2)
+         exp  ->  exp . '*' exp   (rule 3)
+         exp  ->  exp . '/' exp   (rule 4)
+
+         $           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 if `+', it
+will be shifted on the parse stack, and the automaton control will jump
+to state 4, corresponding to the item `exp -> exp '+' . exp'.  Since
+there is no default action, any other token than those listed above
+will trigger a syntax error.
+
+   The state 3 is named the "final state", or the "accepting state":
+
+     state 3
+
+         $accept  ->  exp $ .   (rule 0)
+
+         $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
+
+         exp  ->  exp '+' . exp   (rule 1)
+
+         NUM         shift, and go to state 1
+
+         exp         go to state 8
+
+     state 5
+
+         exp  ->  exp '-' . exp   (rule 2)
+
+         NUM         shift, and go to state 1
+
+         exp         go to state 9
+
+     state 6
+
+         exp  ->  exp '*' . exp   (rule 3)
+
+         NUM         shift, and go to state 1
+
+         exp         go to state 10
+
+     state 7
+
+         exp  ->  exp '/' . exp   (rule 4)
+
+         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
+
+         exp  ->  exp . '+' exp   (rule 1)
+         exp  ->  exp '+' exp .   (rule 1)
+         exp  ->  exp . '-' exp   (rule 2)
+         exp  ->  exp . '*' exp   (rule 3)
+         exp  ->  exp . '/' exp   (rule 4)
+
+         '*'         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 LALR(1) 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 in 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
+
+         exp  ->  exp . '+' exp   (rule 1)
+         exp  ->  exp '+' exp .  [$, '+', '-', '/']   (rule 1)
+         exp  ->  exp . '-' exp   (rule 2)
+         exp  ->  exp . '*' exp   (rule 3)
+         exp  ->  exp . '/' exp   (rule 4)
+
+         '*'         shift, and go to state 6
+         '/'         shift, and go to state 7
+
+         '/'         [reduce using rule 1 (exp)]
+         $default    reduce using rule 1 (exp)
+
+   The remaining states are similar:
+
+     state 9
+
+         exp  ->  exp . '+' exp   (rule 1)
+         exp  ->  exp . '-' exp   (rule 2)
+         exp  ->  exp '-' exp .   (rule 2)
+         exp  ->  exp . '*' exp   (rule 3)
+         exp  ->  exp . '/' exp   (rule 4)
+
+         '*'         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
+
+         exp  ->  exp . '+' exp   (rule 1)
+         exp  ->  exp . '-' exp   (rule 2)
+         exp  ->  exp . '*' exp   (rule 3)
+         exp  ->  exp '*' exp .   (rule 3)
+         exp  ->  exp . '/' exp   (rule 4)
+
+         '/'         shift, and go to state 7
+
+         '/'         [reduce using rule 3 (exp)]
+         $default    reduce using rule 3 (exp)
+
+     state 11
+
+         exp  ->  exp . '+' exp   (rule 1)
+         exp  ->  exp . '-' exp   (rule 2)
+         exp  ->  exp . '*' exp   (rule 3)
+         exp  ->  exp . '/' exp   (rule 4)
+         exp  ->  exp '/' exp .   (rule 4)
+
+         '+'         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.
+
+
+File: bison.info,  Node: Tracing,  Prev: Understanding,  Up: Debugging
+
+8.2 Tracing Your Parser
+=======================
+
+If a Bison grammar compiles properly but doesn't do what you want when
+it runs, the `yydebug' parser-trace feature can help you figure out why.
+
+   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.).
+
+the option `-t', `--debug'
+     Use the `-t' option when you run Bison (*note Invoking Bison:
+     Invocation.).  This is POSIX compliant too.
+
+the directive `%debug'
+     Add the `%debug' directive (*note Bison Declaration Summary: Decl
+     Summary.).  This is a Bison extension, which will prove useful
+     when Bison will output parsers 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 listing
+file produced by the Bison `-v' option (*note Invoking Bison:
+Invocation.).  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 file is a C program and you can use C 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.
+
+   The debugging information normally gives the token type of each token
+read, but not its semantic value.  You can optionally define a macro
+named `YYPRINT' to provide a way to print the 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').
+
+   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);
+     }
+
+
+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 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'.
+
+
+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 output file is called
+     `y.tab.c', and the other outputs are called `y.output' and
+     `y.tab.h'.  Also, if generating an LALR(1) 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'
+`--warnings'
+     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.
+
+    `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-syntax' will hide the warnings about unused
+     variables.
+
+Tuning the parser:
+
+`-t'
+`--debug'
+     In the parser 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.
+
+`-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::.
+
+`-l'
+`--no-lines'
+     Don't put any `#line' preprocessor commands in the parser file.
+     Ordinarily Bison puts them in the parser 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 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 LALR 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 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 LALR(1) grammar 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 LALR(1) 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.)
+
+
+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.
+
+Long Option                Short Option
+------------------------------------------------- 
+`--debug'                  `-t'
+`--defines=[FILE]'         
+`--file-prefix=PREFIX'     `-b' PREFIX
+`--graph=[FILE]'           `-g' [FILE]
+`--help'                   `-h'
+`--language=LANGUAGE'      `-L' LANGUAGE
+`--locations'              
+`--name-prefix=PREFIX'     `-p' PREFIX
+`--no-lines'               `-l'
+`--output=FILE'            `-o' FILE
+`--print-datadir'          
+`--print-localedir'        
+`--report-file=FILE'       
+`--report=THINGS'          `-r' THINGS
+`--skeleton=FILE'          `-S' FILE
+`--token-table'            `-k'
+`--verbose'                `-v'
+`--version'                `-V'
+`--warnings'               `-W'
+`--xml=[FILE]'             `-x' [FILE]
+`--yacc'                   `-y'
+
+
+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);
+
+
+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
+
+
+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
+
+
+File: bison.info,  Node: C++ Bison Interface,  Next: C++ Semantic Values,  Up: C++ Parsers
+
+10.1.1 C++ Bison Interface
+--------------------------
+
+The C++ LALR(1) parser is selected using the skeleton directive,
+`%skeleton "lalr1.c"', or the synonymous command-line option
+`--skeleton=lalr1.c'.  *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 Decl 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 input 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.
+
+
+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.
+
+
+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 Locations Overview: 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).
+
+ -- Method on 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"'.
+
+ -- Method on position: unsigned int line
+     The line, starting at 1.
+
+ -- Method on position: unsigned int lines (int HEIGHT = 1)
+     Advance by HEIGHT lines, resetting the column number.
+
+ -- Method on position: unsigned int column
+     The column, starting at 0.
+
+ -- Method on position: unsigned int columns (int WIDTH = 1)
+     Advance by WIDTH columns, without changing the line number.
+
+ -- Method on position: position& operator+= (position& POS, int WIDTH)
+ -- Method on position: position operator+ (const position& POS, int
+          WIDTH)
+ -- Method on position: position& operator-= (const position& POS, int
+          WIDTH)
+ -- Method on position: position operator- (position& POS, int WIDTH)
+     Various forms of syntactic sugar for `columns'.
+
+ -- Method on position: position operator<< (std::ostream O, const
+          position& P)
+     Report P on O like this: `FILE:LINE.COLUMN', or `LINE.COLUMN' if
+     FILE is null.
+
+ -- Method on location: position begin
+ -- Method on location: position end
+     The first, inclusive, position of the range, and the first beyond.
+
+ -- Method on location: unsigned int columns (int WIDTH = 1)
+ -- Method on location: unsigned int lines (int HEIGHT = 1)
+     Advance the `end' position.
+
+ -- Method on location: location operator+ (const location& BEGIN,
+          const location& END)
+ -- Method on location: location operator+ (const location& BEGIN, int
+          WIDTH)
+ -- Method on location: location operator+= (const location& LOC, int
+          WIDTH)
+     Various forms of syntactic sugar.
+
+ -- Method on location: void step ()
+     Move `begin' onto `end'.
+
+
+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_value_type
+ -- Type of parser: location_value_type
+     The types for semantics value and locations.
+
+ -- 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.
+
+
+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_value_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.
+
+
+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
+
+
+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
+
+
+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;
+     }
+
+
+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 parser definition file `calc++-parser.yy' starts by asking for the
+C++ LALR(1) 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.4.1"
+     %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: Decl 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.  Afterwards 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.
+
+     %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    { debug_stream () << *$$; } "identifier"
+     %destructor { delete $$; } "identifier"
+
+     %printer    { debug_stream () << $$; } <ival>
+
+The grammar itself is straightforward.
+
+     %%
+     %start unit;
+     unit: assignments exp  { driver.result = $2; };
+
+     assignments: assignments assignment {}
+                | /* Nothing.  */        {};
+
+     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);
+     }
+
+
+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 <errno.h>
+     # include <limits.h>
+     # 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 == "-")
+         yyin = stdin;
+       else if (!(yyin = fopen (file.c_str (), "r")))
+         {
+           error (std::string ("cannot open ") + file);
+           exit (1);
+         }
+     }
+
+     void
+     calcxx_driver::scan_end ()
+     {
+       fclose (yyin);
+     }
+
+
+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 (++argv; argv[0]; ++argv)
+         if (*argv == std::string ("-p"))
+           driver.trace_parsing = true;
+         else if (*argv == std::string ("-s"))
+           driver.trace_scanning = true;
+         else if (!driver.parse (*argv))
+           std::cout << driver.result << std::endl;
+     }
+
+
+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
+
+
+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'.  Using an input file
+without a `.y' suffix is currently broken.  The basename of the output
+file can be changed by the `%file-prefix' directive or the
+`-p'/`--name-prefix' option.  The entire output file name can be
+changed by the `%output' directive or the `-o'/`--output' option.  The
+output 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.
+
+
+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.
+
+
+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 Locations Overview: 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.
+
+
+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.
+
+
+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 ther 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 semantical value of the last token that yylex returned.
+
+     The return type can be changed using `%define stype "CLASS-NAME".'
+
+
+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::.
+
+ -- Statement: return YYFAIL;
+     Print an error message and start error recovery.  *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.
+
+
+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.  See
+     *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 backets 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. See
+     *note Java Semantic Values:: and *note Java Action Features::.
+
+   * The prolog 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 (see *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.
+
+
+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::.
+
+
+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
+
+
+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, *Note Recursive Rules:
+Recursion.
+
+
+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)
+    exit (2);
+  /* One token only.  */
+  yylex ();
+  if (fclose (yyin) != 0)
+    exit (3);
+  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)'.
+
+
+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"
+
+
+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.
+
+
+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.  */
+
+
+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.
+
+
+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.
+
+
+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.
+
+
+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 can not provide a fix.
+
+   Send bug reports to <bug-bison@gnu.org>.
+
+
+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.
+
+
+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.
+
+
+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/'.
+
+
+File: bison.info,  Node: Table of Symbols,  Next: Glossary,  Prev: FAQ,  Up: Top
+
+Appendix A Bison Symbols
+************************
+
+ -- Variable: @$
+     In an action, the location of the left-hand side of the rule.
+     *Note Locations Overview: Locations.
+
+ -- Variable: @N
+     In an action, the location of the N-th symbol of the right-hand
+     side of the rule.  *Note Locations Overview: 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::.
+
+ -- 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 directly to the
+     output file uninterpreted.  Such code forms the prologue of the
+     input 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 output parser source.  *Note %code: Decl
+     Summary.
+
+ -- Directive: %debug
+     Equip the parser for debugging.  *Note Decl Summary::.
+
+ -- Directive: %debug
+     Equip the parser for debugging.  *Note Decl Summary::.
+
+ -- Directive: %define DEFINE-VARIABLE
+ -- Directive: %define DEFINE-VARIABLE VALUE
+     Define a variable to adjust Bison's behavior.  *Note %define: Decl
+     Summary.
+
+ -- Directive: %defines
+     Bison declaration to create a header file 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.
+
+ -- 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"
+     Bison declaration to rename the external symbols.  *Note Decl
+     Summary::.
+
+ -- Directive: %no-lines
+     Bison declaration to avoid generating `#line' directives in the
+     parser 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 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 %define: Decl
+     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 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
+     Macro to pretend that a syntax error has just been detected: call
+     `yyerror' and then perform normal error recovery if possible
+     (*note Error Recovery::), or (if recovery is impossible) make
+     `yyparse' return 1.  *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.  Using
+     `%error-verbose' is preferred.
+
+ -- 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.
+
+ -- 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 C LALR(1)
+     parser 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.
+
+
+File: bison.info,  Node: Glossary,  Next: Copying This Manual,  Prev: Table of Symbols,  Up: Top
+
+Appendix B Glossary
+*******************
+
+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.
+
+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.
+
+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 LALR(1).  It resolves situations that
+     Bison's usual LALR(1) 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.
+
+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.
+
+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; a subset of LR(1).  *Note
+     Mysterious Reduce/Reduce Conflicts: Mystery 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.
+
+
+File: bison.info,  Node: Copying This Manual,  Next: Index,  Prev: Glossary,  Up: Top
+
+Appendix C Copying This Manual
+******************************
+
+                      Version 1.2, November 2002
+
+     Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
+     51 Franklin St, Fifth Floor, Boston, MA  02110-1301, USA
+
+     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.
+
+     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 for under this License.  Any other
+     attempt to copy, modify, sublicense or distribute the Document is
+     void, and will automatically terminate your rights under this
+     License.  However, parties who have received copies, or rights,
+     from you under this License will not have their licenses
+     terminated so long as such parties remain in full compliance.
+
+ 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.
+
+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.2
+       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.
+
+
+File: bison.info,  Node: Index,  Prev: Copying This Manual,  Up: Top
+
+Index
+*****
+
+[index]
+* Menu:
+
+* $ <1>:                                 Table of Symbols.    (line  19)
+* $ <2>:                                 Action Features.     (line  14)
+* $:                                     Java Action Features.
+                                                              (line  13)
+* $$ <1>:                                Action Features.     (line  10)
+* $$ <2>:                                Java Action Features.
+                                                              (line  21)
+* $$ <3>:                                Actions.             (line   6)
+* $$:                                    Table of Symbols.    (line  15)
+* $< <1>:                                Java Action Features.
+                                                              (line  17)
+* $< <2>:                                Action Features.     (line  23)
+* $< <3>:                                Java Action Features.
+                                                              (line  29)
+* $<:                                    Action Features.     (line  18)
+* $accept:                               Table of Symbols.    (line  65)
+* $end:                                  Table of Symbols.    (line 104)
+* $N:                                    Actions.             (line   6)
+* $undefined:                            Table of Symbols.    (line 212)
+* % <1>:                                 Java Declarations Summary.
+                                                              (line  53)
+* %:                                     Table of Symbols.    (line  28)
+* %% <1>:                                Table of Symbols.    (line  23)
+* %%:                                    Java Declarations Summary.
+                                                              (line  49)
+* %code <1>:                             Table of Symbols.    (line  71)
+* %code <2>:                             Prologue Alternatives.
+                                                              (line   6)
+* %code <3>:                             Java Declarations Summary.
+                                                              (line  37)
+* %code <4>:                             Calc++ Parser.       (line  64)
+* %code:                                 Decl Summary.        (line  63)
+* %code imports <1>:                     Java Declarations Summary.
+                                                              (line  41)
+* %code imports:                         Decl Summary.        (line 115)
+* %code lexer:                           Java Declarations Summary.
+                                                              (line  45)
+* %code provides <1>:                    Prologue Alternatives.
+                                                              (line   6)
+* %code provides:                        Decl Summary.        (line 303)
+* %code requires <1>:                    Decl Summary.        (line  72)
+* %code requires <2>:                    Calc++ Parser.       (line  17)
+* %code requires:                        Prologue Alternatives.
+                                                              (line   6)
+* %code top <1>:                         Decl Summary.        (line  98)
+* %code top:                             Prologue Alternatives.
+                                                              (line   6)
+* %debug <1>:                            Table of Symbols.    (line  78)
+* %debug <2>:                            Tracing.             (line  23)
+* %debug <3>:                            Decl Summary.        (line 134)
+* %debug:                                Table of Symbols.    (line  75)
+* %define <1>:                           Table of Symbols.    (line  81)
+* %define <2>:                           Decl Summary.        (line 140)
+* %define:                               Table of Symbols.    (line  82)
+* %define abstract:                      Java Declarations Summary.
+                                                              (line  57)
+* %define api.pure <1>:                  Decl Summary.        (line 166)
+* %define api.pure:                      Pure Decl.           (line   6)
+* %define api.push_pull <1>:             Push Decl.           (line   6)
+* %define api.push_pull:                 Decl Summary.        (line 177)
+* %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.keep_unreachable_states:    Decl Summary.        (line 190)
+* %define namespace <1>:                 Decl Summary.        (line 232)
+* %define namespace:                     C++ Bison Interface. (line  10)
+* %define package:                       Java Declarations Summary.
+                                                              (line  84)
+* %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>:                          Table of Symbols.    (line  90)
+* %defines <2>:                          Decl Summary.        (line 307)
+* %defines:                              Table of Symbols.    (line  86)
+* %destructor <1>:                       Destructor Decl.     (line  22)
+* %destructor <2>:                       Decl Summary.        (line 310)
+* %destructor <3>:                       Destructor Decl.     (line   6)
+* %destructor <4>:                       Mid-Rule Actions.    (line  59)
+* %destructor <5>:                       Table of Symbols.    (line  94)
+* %destructor:                           Destructor Decl.     (line  22)
+* %dprec <1>:                            Table of Symbols.    (line  99)
+* %dprec:                                Merging GLR Parses.  (line   6)
+* %error-verbose <1>:                    Table of Symbols.    (line 118)
+* %error-verbose:                        Error Reporting.     (line  17)
+* %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>:                      Decl Summary.        (line 315)
+* %file-prefix:                          Table of Symbols.    (line 122)
+* %glr-parser <1>:                       Simple GLR Parsers.  (line   6)
+* %glr-parser <2>:                       Table of Symbols.    (line 126)
+* %glr-parser:                           GLR Parsers.         (line   6)
+* %initial-action <1>:                   Table of Symbols.    (line 130)
+* %initial-action:                       Initial Action Decl. (line  11)
+* %language <1>:                         Decl Summary.        (line 319)
+* %language:                             Table of Symbols.    (line 134)
+* %language "Java":                      Java Declarations Summary.
+                                                              (line  10)
+* %left <1>:                             Using Precedence.    (line   6)
+* %left <2>:                             Decl Summary.        (line  21)
+* %left:                                 Table of Symbols.    (line 138)
+* %lex-param <1>:                        Table of Symbols.    (line 142)
+* %lex-param <2>:                        Pure Calling.        (line  31)
+* %lex-param:                            Java Declarations Summary.
+                                                              (line  13)
+* %locations:                            Decl Summary.        (line 327)
+* %merge <1>:                            Merging GLR Parses.  (line   6)
+* %merge:                                Table of Symbols.    (line 147)
+* %name-prefix <1>:                      Java Declarations Summary.
+                                                              (line  19)
+* %name-prefix <2>:                      Decl Summary.        (line 334)
+* %name-prefix:                          Table of Symbols.    (line 154)
+* %no-lines <1>:                         Decl Summary.        (line 346)
+* %no-lines:                             Table of Symbols.    (line 158)
+* %nonassoc <1>:                         Table of Symbols.    (line 162)
+* %nonassoc <2>:                         Using Precedence.    (line   6)
+* %nonassoc:                             Decl Summary.        (line  25)
+* %output <1>:                           Decl Summary.        (line 354)
+* %output:                               Table of Symbols.    (line 166)
+* %parse-param <1>:                      Java Declarations Summary.
+                                                              (line  24)
+* %parse-param <2>:                      Parser Function.     (line  36)
+* %parse-param <3>:                      Table of Symbols.    (line 170)
+* %parse-param:                          Parser Function.     (line  36)
+* %prec <1>:                             Table of Symbols.    (line 175)
+* %prec:                                 Contextual Precedence.
+                                                              (line   6)
+* %pure-parser <1>:                      Table of Symbols.    (line 179)
+* %pure-parser:                          Decl Summary.        (line 357)
+* %require <1>:                          Table of Symbols.    (line 184)
+* %require <2>:                          Require Decl.        (line   6)
+* %require:                              Decl Summary.        (line 362)
+* %right <1>:                            Using Precedence.    (line   6)
+* %right <2>:                            Decl Summary.        (line  17)
+* %right:                                Table of Symbols.    (line 188)
+* %skeleton <1>:                         Decl Summary.        (line 366)
+* %skeleton:                             Table of Symbols.    (line 192)
+* %start <1>:                            Table of Symbols.    (line 196)
+* %start <2>:                            Decl Summary.        (line  34)
+* %start:                                Start Decl.          (line   6)
+* %token <1>:                            Decl Summary.        (line  13)
+* %token <2>:                            Token Decl.          (line   6)
+* %token <3>:                            Java Declarations Summary.
+                                                              (line  29)
+* %token:                                Table of Symbols.    (line 200)
+* %token-table <1>:                      Decl Summary.        (line 374)
+* %token-table:                          Table of Symbols.    (line 204)
+* %type <1>:                             Java Declarations Summary.
+                                                              (line  33)
+* %type <2>:                             Type Decl.           (line   6)
+* %type <3>:                             Table of Symbols.    (line 208)
+* %type:                                 Decl Summary.        (line  30)
+* %union <1>:                            Decl Summary.        (line   9)
+* %union <2>:                            Union Decl.          (line   6)
+* %union:                                Table of Symbols.    (line 217)
+* %verbose:                              Decl Summary.        (line 407)
+* %yacc:                                 Decl Summary.        (line 413)
+* *yypstate_new:                         Parser Create Function.
+                                                              (line  15)
+* /*:                                    Table of Symbols.    (line  33)
+* ::                                     Table of Symbols.    (line  36)
+* ;:                                     Table of Symbols.    (line  40)
+* <*> <1>:                               Destructor Decl.     (line   6)
+* <*>:                                   Table of Symbols.    (line  47)
+* <> <1>:                                Destructor Decl.     (line   6)
+* <>:                                    Table of Symbols.    (line  56)
+* @$ <1>:                                Action Features.     (line  98)
+* @$ <2>:                                Java Action Features.
+                                                              (line  39)
+* @$ <3>:                                Table of Symbols.    (line   7)
+* @$:                                    Actions and Locations.
+                                                              (line   6)
+* @N <1>:                                Action Features.     (line 104)
+* @N <2>:                                Actions and Locations.
+                                                              (line   6)
+* @N <3>:                                Table of Symbols.    (line  11)
+* @N <4>:                                Action Features.     (line 104)
+* @N:                                    Java Action Features.
+                                                              (line  35)
+* abstract syntax tree:                  Implementing Gotos/Loops.
+                                                              (line  17)
+* action:                                Actions.             (line   6)
+* action data types:                     Action Types.        (line   6)
+* action features summary:               Action Features.     (line   6)
+* actions in mid-rule <1>:               Mid-Rule Actions.    (line   6)
+* actions in mid-rule:                   Destructor Decl.     (line  88)
+* 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  33)
+* associativity:                         Why Precedence.      (line  33)
+* AST:                                   Implementing Gotos/Loops.
+                                                              (line  17)
+* Backus-Naur form:                      Language and Grammar.
+                                                              (line  16)
+* begin of Location:                     Java Location Values.
+                                                              (line  21)
+* begin on location:                     C++ Location Values. (line  44)
+* 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  31)
+* 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)
+* character token:                       Symbols.             (line  31)
+* column on position:                    C++ Location Values. (line  25)
+* columns on location:                   C++ Location Values. (line  48)
+* columns on position:                   C++ Location Values. (line  28)
+* compiling the parser:                  Rpcalc Compile.      (line   6)
+* conflicts <1>:                         Shift/Reduce.        (line   6)
+* conflicts <2>:                         Merging GLR Parses.  (line   6)
+* conflicts <3>:                         GLR Parsers.         (line   6)
+* conflicts:                             Simple GLR Parsers.  (line   6)
+* conflicts, reduce/reduce:              Reduce/Reduce.       (line   6)
+* conflicts, suppressing warnings of:    Expect Decl.         (line   6)
+* 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 129)
+* 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  31)
+* debug_stream on parser:                C++ Parser Interface.
+                                                              (line  26)
+* 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  50)
+* default data type:                     Value Type.          (line   6)
+* default location type:                 Location Type.       (line   6)
+* default stack limit:                   Memory Management.   (line  30)
+* default start symbol:                  Start Decl.          (line   6)
+* deferred semantic actions:             GLR Semantic Actions.
+                                                              (line   6)
+* defining language semantics:           Semantics.           (line   6)
+* 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:                       Java Location Values.
+                                                              (line  22)
+* end on location:                       C++ Location Values. (line  45)
+* epilogue:                              Epilogue.            (line   6)
+* error <1>:                             Error Recovery.      (line  20)
+* error:                                 Table of Symbols.    (line 108)
+* error on parser:                       C++ Parser Interface.
+                                                              (line  37)
+* 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 on position:                      C++ Location Values. (line  13)
+* 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>:      Generalized LR Parsing.
+                                                              (line   6)
+* generalized LR (GLR) parsing <2>:      Language and Grammar.
+                                                              (line  33)
+* generalized LR (GLR) parsing:          GLR Parsers.         (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>:                       Language and Grammar.
+                                                              (line  33)
+* GLR parsing <2>:                       Generalized LR Parsing.
+                                                              (line   6)
+* GLR parsing:                           GLR Parsers.         (line   6)
+* GLR parsing, ambiguous grammars:       Merging GLR Parses.  (line   6)
+* GLR parsing, unambiguous grammars:     Simple GLR Parsers.  (line   6)
+* 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  47)
+* i18n:                                  Internationalization.
+                                                              (line   6)
+* infix notation calculator:             Infix Calc.          (line   6)
+* 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 107)
+* item set core:                         Understanding.       (line 129)
+* kernel, item set:                      Understanding.       (line 129)
+* LALR(1):                               Mystery Conflicts.   (line  36)
+* LALR(1) grammars:                      Language and Grammar.
+                                                              (line  22)
+* language semantics, defining:          Semantics.           (line   6)
+* layout of Bison grammar:               Grammar Layout.      (line   6)
+* left recursion:                        Recursion.           (line  16)
+* 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 on position:                      C++ Location Values. (line  19)
+* lines on location:                     C++ Location Values. (line  49)
+* lines on position:                     C++ Location Values. (line  22)
+* literal string token:                  Symbols.             (line  53)
+* literal token:                         Symbols.             (line  31)
+* location <1>:                          Locations Overview.  (line   6)
+* location:                              Locations.           (line   6)
+* location actions:                      Actions and Locations.
+                                                              (line   6)
+* Location on Location:                  Java Location Values.
+                                                              (line  25)
+* location tracking calculator:          Location Tracking Calc.
+                                                              (line   6)
+* location, textual <1>:                 Locations.           (line   6)
+* location, textual:                     Locations Overview.  (line   6)
+* location_value_type:                   C++ Parser Interface.
+                                                              (line  16)
+* lookahead token:                       Lookahead.           (line   6)
+* LR(1):                                 Mystery Conflicts.   (line  36)
+* LR(1) 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>:                  Destructor Decl.     (line  88)
+* mid-rule actions:                      Mid-Rule Actions.    (line   6)
+* multi-function calculator:             Multi-function Calc. (line   6)
+* multicharacter literal:                Symbols.             (line  53)
+* mutual recursion:                      Recursion.           (line  32)
+* NLS:                                   Internationalization.
+                                                              (line   6)
+* nondeterministic parsing <1>:          Generalized LR Parsing.
+                                                              (line   6)
+* nondeterministic parsing:              Language and Grammar.
+                                                              (line  33)
+* nonterminal symbol:                    Symbols.             (line   6)
+* nonterminal, useless:                  Understanding.       (line  62)
+* operator precedence:                   Precedence.          (line   6)
+* operator precedence, declaring:        Precedence Decl.     (line   6)
+* operator+ on location:                 C++ Location Values. (line  53)
+* operator+ on position:                 C++ Location Values. (line  33)
+* operator+= on location:                C++ Location Values. (line  57)
+* operator+= on position:                C++ Location Values. (line  31)
+* operator- on position:                 C++ Location Values. (line  36)
+* operator-= on position:                C++ Location Values. (line  35)
+* operator<< on position:                C++ Location Values. (line  40)
+* 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  23)
+* parse on YYParser:                     Java Parser Interface.
+                                                              (line  54)
+* parser:                                Bison Parser.        (line   6)
+* parser on parser:                      C++ Parser Interface.
+                                                              (line  19)
+* parser stack:                          Algorithm.           (line   6)
+* parser stack overflow:                 Memory Management.   (line   6)
+* parser state:                          Parser States.       (line   6)
+* pointed rule:                          Understanding.       (line 107)
+* polish notation calculator:            RPN Calc.            (line   6)
+* 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)
+* Prologue <1>:                          Decl Summary.        (line 129)
+* Prologue <2>:                          Prologue.            (line   6)
+* Prologue:                              Decl Summary.        (line  50)
+* 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  59)
+* 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>:           GLR Parsers.         (line   6)
+* reduce/reduce conflicts <2>:           Simple GLR Parsers.  (line   6)
+* reduce/reduce conflicts:               Merging GLR Parses.  (line   6)
+* reduction:                             Algorithm.           (line   6)
+* reentrant parser:                      Pure Decl.           (line   6)
+* requiring a version of Bison:          Require Decl.        (line   6)
+* return YYABORT;:                       Java Action Features.
+                                                              (line  43)
+* return YYACCEPT;:                      Java Action Features.
+                                                              (line  47)
+* return YYERROR;:                       Java Action Features.
+                                                              (line  51)
+* return YYFAIL;:                        Java Action Features.
+                                                              (line  55)
+* reverse polish notation:               RPN Calc.            (line   6)
+* right recursion:                       Recursion.           (line  16)
+* rpcalc:                                RPN Calc.            (line   6)
+* rule syntax:                           Rules.               (line   6)
+* rule, pointed:                         Understanding.       (line 107)
+* rule, useless:                         Understanding.       (line  62)
+* 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_value_type:                   C++ Parser Interface.
+                                                              (line  15)
+* set_debug_level on parser:             C++ Parser Interface.
+                                                              (line  32)
+* set_debug_stream on parser:            C++ Parser Interface.
+                                                              (line  27)
+* setDebugLevel on YYParser:             Java Parser Interface.
+                                                              (line  68)
+* setDebugStream on YYParser:            Java Parser Interface.
+                                                              (line  63)
+* shift/reduce conflicts <1>:            Simple GLR Parsers.  (line   6)
+* shift/reduce conflicts <2>:            Shift/Reduce.        (line   6)
+* shift/reduce conflicts:                GLR Parsers.         (line   6)
+* shifting:                              Algorithm.           (line   6)
+* simple examples:                       Examples.            (line   6)
+* single-character literal:              Symbols.             (line  31)
+* stack overflow:                        Memory Management.   (line   6)
+* stack, parser:                         Algorithm.           (line   6)
+* stages in using Bison:                 Stages.              (line   6)
+* start symbol:                          Language and Grammar.
+                                                              (line  96)
+* start symbol, declaring:               Start Decl.          (line   6)
+* state (of parser):                     Parser States.       (line   6)
+* step on location:                      C++ Location Values. (line  60)
+* string token:                          Symbols.             (line  53)
+* 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  47)
+* symbols in Bison, table of:            Table of Symbols.    (line   6)
+* syntactic grouping:                    Language and Grammar.
+                                                              (line  47)
+* syntax error:                          Error Reporting.     (line   6)
+* syntax of grammar rules:               Rules.               (line   6)
+* terminal symbol:                       Symbols.             (line   6)
+* textual location <1>:                  Locations Overview.  (line   6)
+* textual location:                      Locations.           (line   6)
+* token:                                 Language and Grammar.
+                                                              (line  47)
+* token type:                            Symbols.             (line   6)
+* token type names, declaring:           Token Decl.          (line   6)
+* token, useless:                        Understanding.       (line  62)
+* toString on Location:                  Java Location Values.
+                                                              (line  32)
+* tracing the parser:                    Tracing.             (line   6)
+* unary operator precedence:             Contextual Precedence.
+                                                              (line   6)
+* useless nonterminal:                   Understanding.       (line  62)
+* useless rule:                          Understanding.       (line  62)
+* useless token:                         Understanding.       (line  62)
+* 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>:                           Table of Symbols.    (line 221)
+* YYABORT:                               Parser Function.     (line  29)
+* YYABORT;:                              Action Features.     (line  28)
+* YYACCEPT <1>:                          Table of Symbols.    (line 230)
+* YYACCEPT:                              Parser Function.     (line  26)
+* YYACCEPT;:                             Action Features.     (line  32)
+* YYBACKUP <1>:                          Table of Symbols.    (line 238)
+* YYBACKUP:                              Action Features.     (line  36)
+* yychar <1>:                            Action Features.     (line  69)
+* yychar <2>:                            Lookahead.           (line  47)
+* yychar <3>:                            Table of Symbols.    (line 242)
+* yychar:                                GLR Semantic Actions.
+                                                              (line  10)
+* yyclearin <1>:                         GLR Semantic Actions.
+                                                              (line  18)
+* yyclearin <2>:                         Table of Symbols.    (line 248)
+* yyclearin:                             Error Recovery.      (line  97)
+* yyclearin;:                            Action Features.     (line  76)
+* yydebug <1>:                           Tracing.             (line   6)
+* yydebug:                               Table of Symbols.    (line 256)
+* YYDEBUG <1>:                           Table of Symbols.    (line 252)
+* YYDEBUG:                               Tracing.             (line  12)
+* YYEMPTY:                               Action Features.     (line  49)
+* YYENABLE_NLS:                          Internationalization.
+                                                              (line  27)
+* YYEOF:                                 Action Features.     (line  52)
+* yyerrok <1>:                           Table of Symbols.    (line 261)
+* yyerrok:                               Error Recovery.      (line  92)
+* yyerrok;:                              Action Features.     (line  81)
+* YYERROR:                               Action Features.     (line  56)
+* yyerror:                               Java Action Features.
+                                                              (line  64)
+* YYERROR:                               Table of Symbols.    (line 265)
+* yyerror <1>:                           Table of Symbols.    (line 274)
+* yyerror:                               Error Reporting.     (line   6)
+* YYERROR:                               GLR Semantic Actions.
+                                                              (line  28)
+* yyerror on Lexer:                      Java Scanner Interface.
+                                                              (line  25)
+* YYERROR;:                              Action Features.     (line  56)
+* YYERROR_VERBOSE:                       Table of Symbols.    (line 278)
+* YYINITDEPTH <1>:                       Table of Symbols.    (line 285)
+* YYINITDEPTH:                           Memory Management.   (line  32)
+* yylex <1>:                             Table of Symbols.    (line 289)
+* 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 294)
+* yylloc <1>:                            Token Locations.     (line   6)
+* yylloc <2>:                            Table of Symbols.    (line 300)
+* yylloc <3>:                            GLR Semantic Actions.
+                                                              (line  10)
+* yylloc <4>:                            Action Features.     (line  86)
+* yylloc <5>:                            Lookahead.           (line  47)
+* yylloc:                                Actions and Locations.
+                                                              (line  60)
+* YYLLOC_DEFAULT:                        Location Default Action.
+                                                              (line   6)
+* YYLTYPE <1>:                           Table of Symbols.    (line 310)
+* YYLTYPE:                               Token Locations.     (line  19)
+* yylval <1>:                            Actions.             (line  74)
+* yylval <2>:                            Action Features.     (line  92)
+* yylval <3>:                            Table of Symbols.    (line 314)
+* yylval <4>:                            GLR Semantic Actions.
+                                                              (line  10)
+* yylval <5>:                            Lookahead.           (line  47)
+* yylval:                                Token Values.        (line   6)
+* YYMAXDEPTH <1>:                        Table of Symbols.    (line 322)
+* YYMAXDEPTH:                            Memory Management.   (line  14)
+* yynerrs <1>:                           Error Reporting.     (line  92)
+* yynerrs:                               Table of Symbols.    (line 326)
+* yyparse <1>:                           Table of Symbols.    (line 332)
+* yyparse:                               Parser Function.     (line   6)
+* YYPARSE_PARAM:                         Table of Symbols.    (line 365)
+* YYParser on YYParser:                  Java Parser Interface.
+                                                              (line  41)
+* YYPRINT:                               Tracing.             (line  71)
+* yypstate_delete <1>:                   Table of Symbols.    (line 336)
+* yypstate_delete:                       Parser Delete Function.
+                                                              (line   6)
+* yypstate_new <1>:                      Parser Create Function.
+                                                              (line   6)
+* yypstate_new:                          Table of Symbols.    (line 344)
+* yypull_parse <1>:                      Pull Parser Function.
+                                                              (line   6)
+* yypull_parse <2>:                      Table of Symbols.    (line 351)
+* yypull_parse:                          Pull Parser Function.
+                                                              (line  14)
+* yypush_parse <1>:                      Push Parser Function.
+                                                              (line  15)
+* yypush_parse:                          Table of Symbols.    (line 358)
+* YYRECOVERING <1>:                      Action Features.     (line  64)
+* YYRECOVERING <2>:                      Error Recovery.      (line 109)
+* YYRECOVERING <3>:                      Action Features.     (line  64)
+* YYRECOVERING:                          Table of Symbols.    (line 371)
+* YYSTACK_USE_ALLOCA:                    Table of Symbols.    (line 376)
+* YYSTYPE:                               Table of Symbols.    (line 392)
+* | <1>:                                 Table of Symbols.    (line  43)
+* |:                                     Rules.               (line  49)
+
+
+
+Tag Table:
+Node: Top1174
+Node: Introduction13739
+Node: Conditions15002
+Node: Copying16893
+Node: Concepts54431
+Node: Language and Grammar55612
+Node: Grammar in Bison61501
+Node: Semantic Values63430
+Node: Semantic Actions65536
+Node: GLR Parsers66723
+Node: Simple GLR Parsers69470
+Node: Merging GLR Parses76122
+Node: GLR Semantic Actions80691
+Node: Compiler Requirements82581
+Node: Locations Overview83317
+Node: Bison Parser84770
+Node: Stages87710
+Node: Grammar Layout88998
+Node: Examples90330
+Node: RPN Calc91533
+Node: Rpcalc Declarations92533
+Node: Rpcalc Rules94461
+Node: Rpcalc Input96277
+Node: Rpcalc Line97752
+Node: Rpcalc Expr98880
+Node: Rpcalc Lexer100847
+Node: Rpcalc Main103441
+Node: Rpcalc Error103848
+Node: Rpcalc Generate104881
+Node: Rpcalc Compile106016
+Node: Infix Calc106895
+Node: Simple Error Recovery109658
+Node: Location Tracking Calc111553
+Node: Ltcalc Declarations112249
+Node: Ltcalc Rules113338
+Node: Ltcalc Lexer115354
+Node: Multi-function Calc117677
+Node: Mfcalc Declarations119253
+Node: Mfcalc Rules121300
+Node: Mfcalc Symbol Table122695
+Node: Exercises128871
+Node: Grammar File129385
+Node: Grammar Outline130234
+Node: Prologue131084
+Node: Prologue Alternatives132873
+Node: Bison Declarations142558
+Node: Grammar Rules142986
+Node: Epilogue143457
+Node: Symbols144473
+Node: Rules151176
+Node: Recursion153655
+Node: Semantics155373
+Node: Value Type156472
+Node: Multiple Types157307
+Node: Actions158474
+Node: Action Types161889
+Node: Mid-Rule Actions163201
+Node: Locations169666
+Node: Location Type170317
+Node: Actions and Locations171103
+Node: Location Default Action173564
+Node: Declarations177284
+Node: Require Decl178811
+Node: Token Decl179130
+Node: Precedence Decl181556
+Node: Union Decl183566
+Node: Type Decl185340
+Node: Initial Action Decl186266
+Node: Destructor Decl187037
+Node: Expect Decl192501
+Node: Start Decl194494
+Node: Pure Decl194882
+Node: Push Decl196632
+Node: Decl Summary201131
+Ref: Decl Summary-Footnote-1218017
+Node: Multiple Parsers218221
+Node: Interface219860
+Node: Parser Function221178
+Node: Push Parser Function223194
+Node: Pull Parser Function224004
+Node: Parser Create Function224655
+Node: Parser Delete Function225478
+Node: Lexical226249
+Node: Calling Convention227681
+Node: Token Values230641
+Node: Token Locations231805
+Node: Pure Calling232699
+Node: Error Reporting234580
+Node: Action Features238710
+Node: Internationalization243012
+Node: Algorithm245553
+Node: Lookahead247919
+Node: Shift/Reduce250128
+Node: Precedence253023
+Node: Why Precedence253679
+Node: Using Precedence255552
+Node: Precedence Examples256529
+Node: How Precedence257239
+Node: Contextual Precedence258396
+Node: Parser States260192
+Node: Reduce/Reduce261436
+Node: Mystery Conflicts264977
+Node: Generalized LR Parsing268684
+Node: Memory Management273303
+Node: Error Recovery275516
+Node: Context Dependency280819
+Node: Semantic Tokens281668
+Node: Lexical Tie-ins284738
+Node: Tie-in Recovery286315
+Node: Debugging288492
+Node: Understanding289158
+Node: Tracing300317
+Node: Invocation304419
+Node: Bison Options305818
+Node: Option Cross Key312822
+Node: Yacc Library313874
+Node: Other Languages314699
+Node: C++ Parsers315026
+Node: C++ Bison Interface315523
+Node: C++ Semantic Values316791
+Ref: C++ Semantic Values-Footnote-1317733
+Node: C++ Location Values317886
+Node: C++ Parser Interface320259
+Node: C++ Scanner Interface321976
+Node: A Complete C++ Example322678
+Node: Calc++ --- C++ Calculator323620
+Node: Calc++ Parsing Driver324134
+Node: Calc++ Parser327915
+Node: Calc++ Scanner331705
+Node: Calc++ Top Level335131
+Node: Java Parsers335780
+Node: Java Bison Interface336457
+Node: Java Semantic Values338420
+Node: Java Location Values340034
+Node: Java Parser Interface341590
+Node: Java Scanner Interface344828
+Node: Java Action Features347013
+Node: Java Differences349740
+Ref: Java Differences-Footnote-1352315
+Node: Java Declarations Summary352465
+Node: FAQ356713
+Node: Memory Exhausted357660
+Node: How Can I Reset the Parser357970
+Node: Strings are Destroyed360239
+Node: Implementing Gotos/Loops361828
+Node: Multiple start-symbols363111
+Node: Secure? Conform?364656
+Node: I can't build Bison365104
+Node: Where can I find help?365822
+Node: Bug Reports366615
+Node: More Languages368076
+Node: Beta Testing368434
+Node: Mailing Lists369308
+Node: Table of Symbols369519
+Node: Glossary384901
+Node: Copying This Manual391798
+Node: Index414191
+
+End Tag Table