@copying
-This manual is for @acronym{GNU} Bison (version @value{VERSION},
-@value{UPDATED}), the @acronym{GNU} parser generator.
+This manual (@value{UPDATED}) is for @acronym{GNU} Bison (version
+@value{VERSION}), the @acronym{GNU} parser generator.
Copyright @copyright{} 1988, 1989, 1990, 1991, 1992, 1993, 1995, 1998,
-1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free
+Software Foundation, Inc.
@quotation
Permission is granted to copy, distribute and/or modify this document
(a) below. A copy of the license is included in the section entitled
``@acronym{GNU} Free Documentation License.''
-(a) The @acronym{FSF}'s Back-Cover Text is: ``You have freedom to copy
-and modify this @acronym{GNU} Manual, like @acronym{GNU} software.
-Copies published by the Free Software Foundation raise funds for
-@acronym{GNU} development.''
+(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and
+modify this @acronym{GNU} manual. Buying copies from the @acronym{FSF}
+supports it in developing @acronym{GNU} and promoting software
+freedom.''
@end quotation
@end copying
@menu
* Introduction::
* Conditions::
-* Copying:: The @acronym{GNU} General Public License says
- how you can copy and share Bison
+* Copying:: The @acronym{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.
+* 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 @code{yyparse}.
-* Algorithm:: How the Bison parser works at run-time.
-* Error Recovery:: Writing rules for error recovery.
+* Grammar File:: Writing Bison declarations and rules.
+* Interface:: C-language interface to the parser function @code{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).
-* C++ Language Interface:: Creating C++ parser objects.
-* 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.
+ 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.
@detailmenu
--- 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.
+* 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 @acronym{GLR} Parsers
-* Simple GLR Parsers:: Using @acronym{GLR} parsers on unambiguous grammars.
-* Merging GLR Parses:: Using @acronym{GLR} parsers to resolve ambiguities.
-* GLR Semantic Actions:: Deferred semantic actions have special concerns.
-* Compiler Requirements:: @acronym{GLR} parsers require a modern C compiler.
+* Simple GLR Parsers:: Using @acronym{GLR} parsers on unambiguous grammars.
+* Merging GLR Parses:: Using @acronym{GLR} parsers to resolve ambiguities.
+* GLR Semantic Actions:: Deferred semantic actions have special concerns.
+* Compiler Requirements:: @acronym{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.
+* 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 @@@var{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.
+* 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
-* Decls: Rpcalc Decls. Prologue (declarations) for rpcalc.
-* Rules: Rpcalc Rules. Grammar Rules for rpcalc, with explanation.
-* Lexer: Rpcalc Lexer. The lexical analyzer.
-* Main: Rpcalc Main. The controlling function.
-* Error: Rpcalc Error. The error reporting function.
-* Gen: Rpcalc Gen. Running Bison on the grammar file.
-* Comp: Rpcalc Compile. Run the C compiler on the output code.
+* 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 @code{rpcalc}
Location Tracking Calculator: @code{ltcalc}
-* Decls: Ltcalc Decls. Bison and C declarations for ltcalc.
-* Rules: Ltcalc Rules. Grammar rules for ltcalc, with explanations.
-* Lexer: Ltcalc Lexer. The lexical analyzer.
+* Ltcalc Declarations:: Bison and C declarations for ltcalc.
+* Ltcalc Rules:: Grammar rules for ltcalc, with explanations.
+* Ltcalc Lexer:: The lexical analyzer.
Multi-Function Calculator: @code{mfcalc}
-* Decl: Mfcalc Decl. Bison declarations for multi-function calculator.
-* Rules: Mfcalc Rules. Grammar rules for the calculator.
-* Symtab: Mfcalc Symtab. Symbol table management subroutines.
+* 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
Outline of a Bison Grammar
-* Prologue:: Syntax and usage of the prologue.
+* 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.
+* 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
* 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 @code{yyparse} and what it returns.
-* Lexical:: You must supply a function @code{yylex}
- which reads tokens.
-* Error Reporting:: You must supply a function @code{yyerror}.
-* Action Features:: Special features for use in actions.
-* Internationalization:: How to let the parser speak in the user's
- native language.
+* Parser Function:: How to call @code{yyparse} and what it returns.
+* Push Parser Function:: How to call @code{yypush_parse} and what it returns.
+* Pull Parser Function:: How to call @code{yypull_parse} and what it returns.
+* Parser Create Function:: How to call @code{yypstate_new} and what it returns.
+* Parser Delete Function:: How to call @code{yypstate_delete} and what it returns.
+* Lexical:: You must supply a function @code{yylex}
+ which reads tokens.
+* Error Reporting:: You must supply a function @code{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 @code{yylex}
* Calling Convention:: How @code{yyparse} calls @code{yylex}.
-* Token Values:: How @code{yylex} must return the semantic value
- of the token it has read.
-* Token Locations:: How @code{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 (@pxref{Pure Decl, ,A Pure (Reentrant) Parser}).
+* Token Values:: How @code{yylex} must return the semantic value
+ of the token it has read.
+* Token Locations:: How @code{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
+ (@pxref{Pure Decl, ,A Pure (Reentrant) Parser}).
The Bison Parser Algorithm
* 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.
+* 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.
+* Using Precedence:: How to specify precedence and associativity.
+* Precedence Only:: How to specify precedence only.
* Precedence Examples:: How these features are used in the previous example.
* How Precedence:: How they work.
* Option Cross Key:: Alphabetical list of long options.
* Yacc Library:: Yacc-compatible @code{yylex} and @code{main}.
-C++ Language Interface
+Parsers Written In Other Languages
* C++ Parsers:: The interface to generate C++ parser classes
-* A Complete C++ Example:: Demonstrating their use
+* Java Parsers:: The interface to generate Java parser classes
C++ Parsers
* 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++ 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:: @code{yyparse} Keeps some State
-* Strings are Destroyed:: @code{yylval} Loses Track of Strings
-* Implementing Gotos/Loops:: Control Flow in the Calculator
-* Multiple start-symbols:: Factoring closely related grammars
-* Secure? Conform?:: Is Bison @acronym{POSIX} safe?
-* I can't build Bison:: Troubleshooting
-* Where can I find help?:: Troubleshouting
-* Bug Reports:: Troublereporting
-* Other Languages:: Parsers in Java and others
-* Beta Testing:: Experimenting development versions
-* Mailing Lists:: Meeting other Bison users
+* Memory Exhausted:: Breaking the Stack Limits
+* How Can I Reset the Parser:: @code{yyparse} Keeps some State
+* Strings are Destroyed:: @code{yylval} Loses Track of Strings
+* Implementing Gotos/Loops:: Control Flow in the Calculator
+* Multiple start-symbols:: Factoring closely related grammars
+* Secure? Conform?:: Is Bison @acronym{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
-* GNU Free Documentation License:: License for copying this manual.
+* Copying This Manual:: License for copying this manual.
@end detailmenu
@end menu
@cindex introduction
@dfn{Bison} is a general-purpose parser generator that converts an
-annotated context-free grammar into an @acronym{LALR}(1) or
-@acronym{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.
+annotated context-free grammar into a deterministic or @acronym{GLR}
+parser employing @acronym{LALR}(1), @acronym{IELR}(1), or canonical
+@acronym{LR}(1) parser tables.
+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
exception@dots{}''. The text spells out the exact terms of the
exception.
-@include gpl.texi
+@node Copying
+@unnumbered GNU GENERAL PUBLIC LICENSE
+@include gpl-3.0.texi
@node Concepts
@chapter The Concepts of Bison
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.
+* 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.
@end menu
@node Language and Grammar
essentially machine-readable @acronym{BNF}.
@cindex @acronym{LALR}(1) grammars
+@cindex @acronym{IELR}(1) grammars
@cindex @acronym{LR}(1) grammars
-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 @acronym{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
-@acronym{LR}(1) grammar, and @acronym{LALR}(1) involves additional
-restrictions that are
-hard to explain simply; but it is rare in actual practice to find an
-@acronym{LR}(1) grammar that fails to be @acronym{LALR}(1).
+There are various important subclasses of context-free grammars.
+Although it can handle almost all context-free grammars, Bison is
+optimized for what are called @acronym{LR}(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.
+For historical reasons, Bison by default is limited by the additional
+restrictions of @acronym{LALR}(1), which is hard to explain simply.
@xref{Mystery Conflicts, ,Mysterious Reduce/Reduce Conflicts}, for
more information on this.
+To escape these additional restrictions, you can request
+@acronym{IELR}(1) or canonical @acronym{LR}(1) parser tables.
+@xref{Decl Summary,,lr.type}, to learn how.
@cindex @acronym{GLR} parsing
@cindex generalized @acronym{LR} (@acronym{GLR}) parsing
@cindex ambiguous grammars
@cindex nondeterministic parsing
-Parsers for @acronym{LALR}(1) grammars are @dfn{deterministic}, meaning
+Parsers for @acronym{LR}(1) grammars are @dfn{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 @dfn{lookahead}) of the remaining input. A context-free
@cindex shift/reduce conflicts
@cindex reduce/reduce conflicts
-In some grammars, Bison's standard
-@acronym{LALR}(1) parsing algorithm cannot decide whether to apply a
+In some grammars, Bison's deterministic
+@acronym{LR}(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
(@pxref{Reduce/Reduce}), and @dfn{shift/reduce} conflicts
(@pxref{Shift/Reduce}).
-To use a grammar that is not easily modified to be @acronym{LALR}(1), a
+To use a grammar that is not easily modified to be @acronym{LR}(1), a
more general parsing algorithm is sometimes necessary. If you include
@code{%glr-parser} among the Bison declarations in your file
(@pxref{Grammar Outline}), the result is a Generalized @acronym{LR}
(@acronym{GLR}) parser. These parsers handle Bison grammars that
contain no unresolved conflicts (i.e., after applying precedence
-declarations) identically to @acronym{LALR}(1) parsers. However, when
+declarations) identically to deterministic parsers. However, when
faced with unresolved shift/reduce and reduce/reduce conflicts,
@acronym{GLR} parsers use the simple expedient of doing both,
effectively cloning the parser to follow both possibilities. Each of
merged result.
@menu
-* Simple GLR Parsers:: Using @acronym{GLR} parsers on unambiguous grammars.
-* Merging GLR Parses:: Using @acronym{GLR} parsers to resolve ambiguities.
-* GLR Semantic Actions:: Deferred semantic actions have special concerns.
-* Compiler Requirements:: @acronym{GLR} parsers require a modern C compiler.
+* Simple GLR Parsers:: Using @acronym{GLR} parsers on unambiguous grammars.
+* Merging GLR Parses:: Using @acronym{GLR} parsers to resolve ambiguities.
+* GLR Semantic Actions:: Deferred semantic actions have special concerns.
+* Compiler Requirements:: @acronym{GLR} parsers require a modern C compiler.
@end menu
@node Simple GLR Parsers
@cindex shift/reduce conflicts
In the simplest cases, you can use the @acronym{GLR} algorithm
-to parse grammars that are unambiguous, but fail to be @acronym{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
-@acronym{LALR}(1) algorithm throws away too much information (they are in
-@acronym{LR}(1), but not @acronym{LALR}(1), @ref{Mystery Conflicts}).
+to parse grammars that are unambiguous but fail to be @acronym{LR}(1).
+Such grammars typically require more than one symbol of lookahead.
Consider a problem that
arises in the declaration of enumerated and subrange types in the
valid, and more-complicated cases can come up in practical programs.)
These two declarations look identical until the @samp{..} token.
-With normal @acronym{LALR}(1) one-token lookahead it is not
+With normal @acronym{LR}(1) one-token lookahead it is not
possible to decide between the two forms when the identifier
@samp{a} is parsed. It is, however, desirable
for a parser to decide this, since in the latter case
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 @acronym{LALR}(1) algorithm actually allows
-for. In this example, @acronym{LALR}(2) would suffice, but also some cases
-that are not @acronym{LALR}(@math{k}) for any @math{k} can be handled this way.
+lookahead than the underlying @acronym{LR}(1) algorithm actually allows
+for. In this example, @acronym{LR}(2) would suffice, but also some cases
+that are not @acronym{LR}(@math{k}) for any @math{k} can be handled this way.
In general, a @acronym{GLR} parser can take quadratic or cubic worst-case time,
and the current Bison parser even takes exponential time and space
@end group
@end example
-When used as a normal @acronym{LALR}(1) grammar, Bison correctly complains
+When used as a normal @acronym{LR}(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
analyze the conflicts reported by Bison to make sure that @acronym{GLR}
splitting is only done where it is intended. A @acronym{GLR} parser
splitting inadvertently may cause problems less obvious than an
-@acronym{LALR} parser statically choosing the wrong alternative in a
+@acronym{LR} parser statically choosing the wrong alternative in a
conflict. Second, consider interactions with the lexer (@pxref{Semantic
Tokens}) with great care. Since a split parser consumes tokens without
performing any actions during the split, the lexer cannot obtain
(@pxref{Action Features}), which you can invoke in a semantic action to
initiate error recovery.
During deterministic @acronym{GLR} operation, the effect of @code{YYERROR} is
-the same as its effect in an @acronym{LALR}(1) parser.
+the same as its effect in a deterministic parser.
In a deferred semantic action, its effect is undefined.
@c The effect is probably a syntax error at the split point.
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.
+* 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 @@@var{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.
+* 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.
@end menu
@node RPN Calc
@samp{.y} extension is a convention used for Bison input files.
@menu
-* Decls: Rpcalc Decls. Prologue (declarations) for rpcalc.
-* Rules: Rpcalc Rules. Grammar Rules for rpcalc, with explanation.
-* Lexer: Rpcalc Lexer. The lexical analyzer.
-* Main: Rpcalc Main. The controlling function.
-* Error: Rpcalc Error. The error reporting function.
-* Gen: Rpcalc Gen. Running Bison on the grammar file.
-* Comp: Rpcalc Compile. Run the C compiler on the output code.
+* 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.
@end menu
-@node Rpcalc Decls
+@node Rpcalc Declarations
@subsection Declarations for @code{rpcalc}
Here are the C and Bison declarations for the reverse polish notation
The semantic value of the token (if it has one) is stored into the
global variable @code{yylval}, which is where the Bison parser will look
for it. (The C data type of @code{yylval} is @code{YYSTYPE}, which was
-defined at the beginning of the grammar; @pxref{Rpcalc Decls,
+defined at the beginning of the grammar; @pxref{Rpcalc Declarations,
,Declarations for @code{rpcalc}}.)
A token type code of zero is returned if the end-of-input is encountered.
cause the calculator program to exit. This is not clean behavior for a
real calculator, but it is adequate for the first example.
-@node Rpcalc Gen
+@node Rpcalc Generate
@subsection Running Bison to Make the Parser
@cindex running Bison (introduction)
%token NUM
%left '-' '+'
%left '*' '/'
-%left NEG /* negation--unary minus */
-%right '^' /* exponentiation */
+%precedence NEG /* negation--unary minus */
+%right '^' /* exponentiation */
%% /* The grammar follows. */
input: /* empty */
types and says they are left-associative operators. The declarations
@code{%left} and @code{%right} (right associativity) take the place of
@code{%token} which is used to declare a token type name without
-associativity. (These tokens are single-character literals, which
+associativity/precedence. (These tokens are single-character literals, which
ordinarily don't need to be declared. We declare them here to specify
-the associativity.)
+the associativity/precedence.)
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 (@code{NEG}) is next, followed
-by @samp{*} and @samp{/}, and so on. @xref{Precedence, ,Operator
+by @samp{*} and @samp{/}, and so on. Unary minus is not associative,
+only precedence matters (@code{%precedence}. @xref{Precedence, ,Operator
Precedence}.
The other important new feature is the @code{%prec} in the grammar
analyzer.
@menu
-* Decls: Ltcalc Decls. Bison and C declarations for ltcalc.
-* Rules: Ltcalc Rules. Grammar rules for ltcalc, with explanations.
-* Lexer: Ltcalc Lexer. The lexical analyzer.
+* Ltcalc Declarations:: Bison and C declarations for ltcalc.
+* Ltcalc Rules:: Grammar rules for ltcalc, with explanations.
+* Ltcalc Lexer:: The lexical analyzer.
@end menu
-@node Ltcalc Decls
+@node Ltcalc Declarations
@subsection Declarations for @code{ltcalc}
The C and Bison declarations for the location tracking calculator are
%left '-' '+'
%left '*' '/'
-%left NEG
+%precedence NEG
%right '^'
%% /* The grammar follows. */
Note that multiple assignment and nested function calls are permitted.
@menu
-* Decl: Mfcalc Decl. Bison declarations for multi-function calculator.
-* Rules: Mfcalc Rules. Grammar rules for the calculator.
-* Symtab: Mfcalc Symtab. Symbol table management subroutines.
+* Mfcalc Declarations:: Bison declarations for multi-function calculator.
+* Mfcalc Rules:: Grammar rules for the calculator.
+* Mfcalc Symbol Table:: Symbol table management subroutines.
@end menu
-@node Mfcalc Decl
+@node Mfcalc Declarations
@subsection Declarations for @code{mfcalc}
Here are the C and Bison declarations for the multi-function calculator.
%right '='
%left '-' '+'
%left '*' '/'
-%left NEG /* negation--unary minus */
-%right '^' /* exponentiation */
+%precedence NEG /* negation--unary minus */
+%right '^' /* exponentiation */
@end group
%% /* The grammar follows. */
@end smallexample
%%
@end smallexample
-@node Mfcalc Symtab
+@node Mfcalc Symbol Table
@subsection The @code{mfcalc} Symbol Table
@cindex symbol table example
continues until end of line.
@menu
-* Prologue:: Syntax and usage of the prologue.
+* 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.
+* 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.
@end menu
@node Prologue
@findex %code requires
@findex %code provides
@findex %code top
-(The prologue alternatives described here are experimental.
-More user feedback will help to determine whether they should become permanent
-features.)
The functionality of @var{Prologue} sections can often be subtle and
inflexible.
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
-@code{requires}, @code{provides}, or @code{top}.
-@xref{Table of Symbols,,Bison Symbols}.
+one of @code{requires}, @code{provides}, @code{top}.
+@xref{Decl Summary,,%code}.
Look again at the example of the previous section:
The first line after the warning is required by @code{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
-(@pxref{Table of Symbols, ,%defines}), you probably want that line to appear
-before the @code{YYSTYPE} definition in that header file as well.
+(@pxref{Decl Summary, ,%defines}), you probably want that line to appear before
+the @code{YYSTYPE} definition in that header file as well.
The @code{YYLTYPE} definition should also appear in the parser header file to
override the default @code{YYLTYPE} definition there.
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 @code{%union}) in the
definitions section is going to adversely affect their functionality in some
counter-intuitive manner just because it comes first.
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.
+Symbol names can contain letters, underscores, periods, dashes, and (not
+at the beginning) digits. Dashes in symbol names are a GNU
+extension, incompatible with @acronym{POSIX} Yacc. Terminal symbols
+that contain periods or dashes make little sense: since they are not
+valid symbols (in most programming languages) they are not exported as
+token names.
There are three ways of writing terminal symbols in the grammar:
@} YYLTYPE;
@end example
-At the beginning of the parsing, Bison initializes all these fields to 1
-for @code{yylloc}.
+When @code{YYLTYPE} is not defined, at the beginning of the parsing, Bison
+initializes all these fields to 1 for @code{yylloc}. To initialize
+@code{yylloc} with a custom location type (or to chose a different
+initialization), use the @code{%initial-action} directive. @xref{Initial
+Action Decl, , Performing Actions before Parsing}.
@node Actions and Locations
@subsection Actions and Locations
* 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.
@end menu
the parser, so that the function @code{yylex} (if it is in this file)
can use the name @var{name} to stand for this token type's code.
-Alternatively, you can use @code{%left}, @code{%right}, or
+Alternatively, you can use @code{%left}, @code{%right},
+@code{%precedence}, or
@code{%nonassoc} instead of @code{%token}, if you wish to specify
associativity and precedence. @xref{Precedence Decl, ,Operator
Precedence}.
You can explicitly specify the numeric code for a token type by appending
-a decimal or hexadecimal integer value in the field immediately
+a nonnegative decimal or hexadecimal integer value in the field immediately
following the token name:
@example
interchangeably in further declarations or the grammar rules. The
@code{yylex} function can use the token name or the literal string to
obtain the token type code number (@pxref{Calling Convention}).
+Syntax error messages passed to @code{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'':
+
+@example
+%token END 0 "end of file"
+@end example
@node Precedence Decl
@subsection Operator Precedence
@cindex declaring operator precedence
@cindex operator precedence, declaring
-Use the @code{%left}, @code{%right} or @code{%nonassoc} declaration to
+Use the @code{%left}, @code{%right}, @code{%nonassoc}, or
+@code{%precedence} declaration to
declare a token and specify its precedence and associativity, all at
once. These are called @dfn{precedence declarations}.
@xref{Precedence, ,Operator Precedence}, for general information on
operator precedence.
-The syntax of a precedence declaration is the same as that of
+The syntax of a precedence declaration is nearly the same as that of
@code{%token}: either
@example
means that @samp{@var{x} @var{op} @var{y} @var{op} @var{z}} is
considered a syntax error.
+@code{%precedence} gives only precedence to the @var{symbols}, and
+defines no associativity at all. Use this to define precedence only,
+and leave any potential conflict due to associativity enabled.
+
@item
The precedence of an operator determines how it nests with other operators.
All the tokens declared in a single precedence declaration have equal
the one declared later has the higher precedence and is grouped first.
@end itemize
+For backward compatibility, there is a confusing difference between the
+argument lists of @code{%token} and precedence declarations.
+Only a @code{%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:
+
+@example
+%left OR "<=" // Does not declare an alias.
+%left OR 134 "<=" 135 // Declares 134 for OR and 135 for "<=".
+@end example
+
@node Union Decl
@subsection The Collection of Value Types
@cindex declaring value types
@code{YYABORT} or @code{YYACCEPT}, or failed error recovery, or memory
exhaustion.
-Right-hand size symbols of a rule that explicitly triggers a syntax
+Right-hand side symbols of a rule that explicitly triggers a syntax
error via @code{YYERROR} are not discarded automatically. As a rule
of thumb, destructors are invoked only when user actions cannot manage
the memory.
Bison reports an error if the number of shift/reduce conflicts differs
from @var{n}, or if there are any reduce/reduce conflicts.
-For normal @acronym{LALR}(1) parsers, reduce/reduce conflicts are more
+For deterministic parsers, reduce/reduce conflicts are more
serious, and should be eliminated entirely. Bison will always report
reduce/reduce conflicts for these parsers. With @acronym{GLR}
parsers, however, both kinds of conflicts are routine; otherwise,
@subsection A Pure (Reentrant) Parser
@cindex reentrant parser
@cindex pure parser
-@findex %pure-parser
+@findex %define api.pure
A @dfn{reentrant} program is one which does not alter in the course of
execution; in other words, it consists entirely of @dfn{pure} (read-only)
including @code{yylval} and @code{yylloc}.)
Alternatively, you can generate a pure, reentrant parser. The Bison
-declaration @code{%pure-parser} says that you want the parser to be
+declaration @samp{%define api.pure} says that you want the parser to be
reentrant. It looks like this:
@example
-%pure-parser
+%define api.pure
@end example
The result is that the communication variables @code{yylval} and
@code{yylloc} become local variables in @code{yyparse}, and a different
calling convention is used for the lexical analyzer function
@code{yylex}. @xref{Pure Calling, ,Calling Conventions for Pure
-Parsers}, for the details of this. The variable @code{yynerrs} also
-becomes local in @code{yyparse} (@pxref{Error Reporting, ,The Error
+Parsers}, for the details of this. The variable @code{yynerrs}
+becomes local in @code{yyparse} in pull mode but it becomes a member
+of yypstate in push mode. (@pxref{Error Reporting, ,The Error
Reporting Function @code{yyerror}}). The convention for calling
@code{yyparse} itself is unchanged.
You can generate either a pure parser or a nonreentrant parser from any
valid grammar.
+@node Push Decl
+@subsection A Push Parser
+@cindex push parser
+@cindex push parser
+@findex %define api.push-pull
+
+(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 (@pxref{Decl Summary,,%define api.push-pull}):
+
+@example
+%define api.push-pull push
+@end example
+
+In almost all cases, you want to ensure that your push parser is also
+a pure parser (@pxref{Pure Decl, ,A Pure (Reentrant) Parser}). 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:
+
+@example
+%define api.pure
+%define api.push-pull push
+@end example
+
+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. @code{yypstate} is a structure that the generated
+parser uses to store the parser's state. @code{yypstate_new} is the
+function that will create a new parser instance. @code{yypstate_delete}
+will free the resources associated with the corresponding parser instance.
+Finally, @code{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:
+
+@example
+int status;
+yypstate *ps = yypstate_new ();
+do @{
+ status = yypush_parse (ps, yylex (), NULL);
+@} while (status == YYPUSH_MORE);
+yypstate_delete (ps);
+@end example
+
+If the user decided to use an impure push parser, a few things about
+the generated parser will change. The @code{yychar} variable becomes
+a global variable instead of a variable in the @code{yypush_parse} function.
+For this reason, the signature of the @code{yypush_parse} function is
+changed to remove the token as a parameter. A nonreentrant push parser
+example would thus look like this:
+
+@example
+extern int yychar;
+int status;
+yypstate *ps = yypstate_new ();
+do @{
+ yychar = yylex ();
+ status = yypush_parse (ps);
+@} while (status == YYPUSH_MORE);
+yypstate_delete (ps);
+@end example
+
+That's it. Notice the next token is put into the global variable @code{yychar}
+for use by the next invocation of the @code{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 @samp{%define api.push-pull push} declaration with the
+@samp{%define api.push-pull both} declaration. Doing this will create all of
+the symbols mentioned earlier along with the two extra symbols, @code{yyparse}
+and @code{yypull_parse}. @code{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 @code{yypull_parse}.
+This makes the @code{yyparse} function that is generated with the
+@samp{%define api.push-pull both} declaration slower than the normal
+@code{yyparse} function. If the user
+calls the @code{yypull_parse} function it will parse the rest of the input
+stream. It is possible to @code{yypush_parse} tokens to select a subgrammar
+and then @code{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 @code{yypull_parse} function that knows when to quit looking
+for input. An example of using the @code{yypull_parse} function would look
+like this:
+
+@example
+yypstate *ps = yypstate_new ();
+yypull_parse (ps); /* Will call the lexer */
+yypstate_delete (ps);
+@end example
+
+Adding the @samp{%define api.pure} declaration does exactly the same thing to
+the generated parser with @samp{%define api.push-pull both} as it did for
+@samp{%define api.push-pull push}.
+
@node Decl Summary
@subsection Bison Declaration Summary
@cindex Bison declaration summary
In order to change the behavior of @command{bison}, use the following
directives:
-@deffn {Directive} %debug
-In the parser file, define the macro @code{YYDEBUG} to 1 if it is not
-already defined, so that the debugging facilities are compiled.
+@deffn {Directive} %code @{@var{code}@}
+@findex %code
+This is the unqualified form of the @code{%code} directive.
+It inserts @var{code} verbatim at a language-dependent default location in the
+output@footnote{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.}.
+
+@cindex Prologue
+For C/C++, the default location is the parser source code
+file after the usual contents of the parser header file.
+Thus, @code{%code} replaces the traditional Yacc prologue,
+@code{%@{@var{code}%@}}, for most purposes.
+For a detailed discussion, see @ref{Prologue Alternatives}.
+
+For Java, the default location is inside the parser class.
@end deffn
-@xref{Tracing, ,Tracing Your Parser}.
-@deffn {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 @file{@var{name}.c} then this file
-is named @file{@var{name}.h}.
+@deffn {Directive} %code @var{qualifier} @{@var{code}@}
+This is the qualified form of the @code{%code} directive.
+If you need to specify location-sensitive verbatim @var{code} that does not
+belong at the default location selected by the unqualified @code{%code} form,
+use this form instead.
-For C parsers, the output header declares @code{YYSTYPE} unless
-@code{YYSTYPE} is already defined as a macro or you have used a
-@code{<@var{type}>} tag without using @code{%union}.
-Therefore, if you are using a @code{%union}
-(@pxref{Multiple Types, ,More Than One Value Type}) with components that
-require other definitions, or if you have defined a @code{YYSTYPE} macro
-or type definition
-(@pxref{Value Type, ,Data Types of Semantic Values}), 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 @code{YYSTYPE}.
+@var{qualifier} identifies the purpose of @var{code} and thus the location(s)
+where Bison should generate it.
+Not all @var{qualifier}s are accepted for all target languages.
+Unaccepted @var{qualifier}s produce an error.
+Some of the accepted @var{qualifier}s are:
-Unless your parser is pure, the output header declares @code{yylval}
-as an external variable. @xref{Pure Decl, ,A Pure (Reentrant)
-Parser}.
+@itemize @bullet
+@item requires
+@findex %code requires
-If you have also used locations, the output header declares
-@code{YYLTYPE} and @code{yylloc} using a protocol similar to that of
-the @code{YYSTYPE} macro and @code{yylval}. @xref{Locations, ,Tracking
-Locations}.
+@itemize @bullet
+@item Language(s): C, C++
-This output file is normally essential if you wish to put the definition
-of @code{yylex} in a separate source file, because @code{yylex}
-typically needs to be able to refer to the above-mentioned declarations
-and to the token type codes. @xref{Token Values, ,Semantic Values of
-Tokens}.
+@item Purpose: This is the best place to write dependency code required for
+@code{YYSTYPE} and @code{YYLTYPE}.
+In other words, it's the best place to define types referenced in @code{%union}
+directives, and it's the best place to override Bison's default @code{YYSTYPE}
+and @code{YYLTYPE} definitions.
-@findex %code requires
+@item Location(s): The parser header file and the parser source code file
+before the Bison-generated @code{YYSTYPE} and @code{YYLTYPE} definitions.
+@end itemize
+
+@item provides
@findex %code provides
-If you have declared @code{%code requires} or @code{%code provides}, the output
-header also contains their code.
-@xref{Table of Symbols, ,%code}.
-@end deffn
-@deffn {Directive} %defines @var{defines-file}
-Same as above, but save in the file @var{defines-file}.
-@end deffn
+@itemize @bullet
+@item Language(s): C, C++
-@deffn {Directive} %destructor
-Specify how the parser should reclaim the memory associated to
-discarded symbols. @xref{Destructor Decl, , Freeing Discarded Symbols}.
-@end deffn
+@item Purpose: This is the best place to write additional definitions and
+declarations that should be provided to other modules.
-@deffn {Directive} %file-prefix "@var{prefix}"
-Specify a prefix to use for all Bison output file names. The names are
-chosen as if the input file were named @file{@var{prefix}.y}.
-@end deffn
+@item Location(s): The parser header file and the parser source code file after
+the Bison-generated @code{YYSTYPE}, @code{YYLTYPE}, and token definitions.
+@end itemize
-@deffn {Directive} %language "@var{language}"
-Specify the programming language for the generated parser. Currently
-supported languages include C and C++.
-@var{language} is case-insensitive.
-@end deffn
+@item top
+@findex %code top
-@deffn {Directive} %locations
-Generate the code processing the locations (@pxref{Action Features,
-,Special Features for Use in Actions}). This mode is enabled as soon as
-the grammar uses the special @samp{@@@var{n}} tokens, but if your
-grammar does not use it, using @samp{%locations} allows for more
-accurate syntax error messages.
-@end deffn
+@itemize @bullet
+@item Language(s): C, C++
-@deffn {Directive} %name-prefix "@var{prefix}"
-Rename the external symbols used in the parser so that they start with
-@var{prefix} instead of @samp{yy}. The precise list of symbols renamed
-in C parsers
-is @code{yyparse}, @code{yylex}, @code{yyerror}, @code{yynerrs},
-@code{yylval}, @code{yychar}, @code{yydebug}, and
-(if locations are used) @code{yylloc}. For example, if you use
-@samp{%name-prefix "c_"}, the names become @code{c_parse}, @code{c_lex},
-and so on. In C++ parsers, it is only the surrounding namespace which is
-named @var{prefix} instead of @samp{yy}.
-@xref{Multiple Parsers, ,Multiple Parsers in the Same Program}.
-@end deffn
+@item Purpose: The unqualified @code{%code} or @code{%code requires} should
+usually be more appropriate than @code{%code top}.
+However, occasionally it is necessary to insert code much nearer the top of the
+parser source code file.
+For example:
-@ifset defaultprec
-@deffn {Directive} %no-default-prec
-Do not assign a precedence to rules lacking an explicit @code{%prec}
-modifier (@pxref{Contextual Precedence, ,Context-Dependent
-Precedence}).
-@end deffn
-@end ifset
+@smallexample
+%code top @{
+ #define _GNU_SOURCE
+ #include <stdio.h>
+@}
+@end smallexample
-@deffn {Directive} %no-parser
-Do not include any C code in the parser file; generate tables only. The
-parser file contains just @code{#define} directives and static variable
-declarations.
+@item Location(s): Near the top of the parser source code file.
+@end itemize
-This option also tells Bison to write the C code for the grammar actions
-into a file named @file{@var{file}.act}, in the form of a
-brace-surrounded body fit for a @code{switch} statement.
-@end deffn
+@item imports
+@findex %code imports
-@deffn {Directive} %no-lines
-Don't generate any @code{#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.
-@end deffn
+@itemize @bullet
+@item Language(s): Java
-@deffn {Directive} %output "@var{file}"
-Specify @var{file} for the parser file.
-@end deffn
+@item Purpose: This is the best place to write Java import directives.
-@deffn {Directive} %pure-parser
-Request a pure (reentrant) parser program (@pxref{Pure Decl, ,A Pure
-(Reentrant) Parser}).
-@end deffn
+@item Location(s): The parser Java file after any Java package directive and
+before any class definitions.
+@end itemize
+@end itemize
-@deffn {Directive} %require "@var{version}"
-Require version @var{version} or higher of Bison. @xref{Require Decl, ,
-Require a Version of Bison}.
+@cindex Prologue
+For a detailed discussion of how to use @code{%code} in place of the
+traditional Yacc prologue for C/C++, see @ref{Prologue Alternatives}.
@end deffn
-@deffn {Directive} %skeleton "@var{file}"
-Specify the skeleton to use. You probably don't need this option unless
-you are developing Bison; you should use @code{%language} if you want to
-specify the skeleton for a different language, because it is clearer and
-because it will always choose the correct skeleton for non-deterministic
-or push parsers.
+@deffn {Directive} %debug
+Instrument the output parser for traces. Obsoleted by @samp{%define
+parse.trace}.
+@xref{Tracing, ,Tracing Your Parser}.
@end deffn
-@deffn {Directive} %token-table
-Generate an array of token names in the parser file. The name of the
-array is @code{yytname}; @code{yytname[@var{i}]} is the name of the
-token whose internal Bison token code number is @var{i}. The first
-three elements of @code{yytname} correspond to the predefined tokens
-@code{"$end"},
-@code{"error"}, and @code{"$undefined"}; after these come the symbols
-defined in the grammar file.
+@deffn {Directive} %define @var{variable}
+@deffnx {Directive} %define @var{variable} @var{value}
+@deffnx {Directive} %define @var{variable} "@var{value}"
+Define a variable to adjust Bison's behavior.
-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
-@code{'+'} corresponds to a three-character name, represented in C as
-@code{"'+'"}; and the Bison two-character literal string @code{"\\/"}
-corresponds to a five-character name, represented in C as
-@code{"\"\\\\/\""}.
+It is an error if a @var{variable} is defined by @code{%define} multiple
+times, but see @ref{Bison Options,,-D @var{name}[=@var{value}]}.
-When you specify @code{%token-table}, Bison also generates macro
-definitions for macros @code{YYNTOKENS}, @code{YYNNTS}, and
-@code{YYNRULES}, and @code{YYNSTATES}:
+@var{value} must be placed in quotation marks if it contains any
+character other than a letter, underscore, period, dash, or non-initial
+digit.
-@table @code
-@item YYNTOKENS
-The highest token number, plus one.
-@item YYNNTS
-The number of nonterminal symbols.
-@item YYNRULES
-The number of grammar rules,
-@item YYNSTATES
-The number of parser states (@pxref{Parser States}).
-@end table
-@end deffn
+Omitting @code{"@var{value}"} entirely is always equivalent to specifying
+@code{""}.
-@deffn {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. @xref{Understanding, , Understanding Your Parser}, for more
-information.
-@end deffn
+Some @var{variable}s take Boolean values.
+In this case, Bison will complain if the variable definition does not meet one
+of the following four conditions:
-@deffn {Directive} %yacc
-Pretend the option @option{--yacc} was given, i.e., imitate Yacc,
-including its naming conventions. @xref{Bison Options}, for more.
-@end deffn
+@enumerate
+@item @code{@var{value}} is @code{true}
+@item @code{@var{value}} is omitted (or @code{""} is specified).
+This is equivalent to @code{true}.
-@node Multiple Parsers
-@section Multiple Parsers in the Same Program
+@item @code{@var{value}} is @code{false}.
-Most programs that use Bison parse only one language and therefore contain
-only one Bison parser. But what if you want to parse more than one
-language with the same program? Then you need to avoid a name conflict
-between different definitions of @code{yyparse}, @code{yylval}, and so on.
+@item @var{variable} is never defined.
+In this case, Bison selects a default value.
+@end enumerate
-The easy way to do this is to use the option @samp{-p @var{prefix}}
-(@pxref{Invocation, ,Invoking Bison}). This renames the interface
-functions and variables of the Bison parser to start with @var{prefix}
-instead of @samp{yy}. You can use this to give each parser distinct
-names that do not conflict.
+What @var{variable}s are accepted, as well as their meanings and default
+values, depend on the selected target language and/or the parser
+skeleton (@pxref{Decl Summary,,%language}, @pxref{Decl
+Summary,,%skeleton}).
+Unaccepted @var{variable}s produce an error.
+Some of the accepted @var{variable}s are:
-The precise list of symbols renamed is @code{yyparse}, @code{yylex},
-@code{yyerror}, @code{yynerrs}, @code{yylval}, @code{yylloc},
-@code{yychar} and @code{yydebug}. For example, if you use @samp{-p c},
-the names become @code{cparse}, @code{clex}, and so on.
+@table @code
+@c ================================================== namespace
+@item api.namespace
+@findex %define api.namespace
+@itemize
+@item Languages(s): C++
-@strong{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, @code{YYSTYPE} is not
-renamed, but defining this in different ways in different parsers causes
-no trouble (@pxref{Value Type, ,Data Types of Semantic Values}).
+@item Purpose: Specifies the namespace for the parser class.
+For example, if you specify:
-The @samp{-p} option works by adding macro definitions to the beginning
-of the parser source file, defining @code{yyparse} as
-@code{@var{prefix}parse}, and so on. This effectively substitutes one
-name for the other in the entire parser file.
+@smallexample
+%define api.namespace "foo::bar"
+@end smallexample
-@node Interface
-@chapter Parser C-Language Interface
-@cindex C-language interface
-@cindex interface
+Bison uses @code{foo::bar} verbatim in references such as:
-The Bison parser is actually a C function named @code{yyparse}. Here we
-describe the interface conventions of @code{yyparse} and the other
-functions that it needs to use.
+@smallexample
+foo::bar::parser::semantic_type
+@end smallexample
-Keep in mind that the parser uses many C identifiers starting with
-@samp{yy} and @samp{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.
+However, to open a namespace, Bison removes any leading @code{::} and then
+splits on any remaining occurrences:
-@menu
-* Parser Function:: How to call @code{yyparse} and what it returns.
-* Lexical:: You must supply a function @code{yylex}
- which reads tokens.
-* Error Reporting:: You must supply a function @code{yyerror}.
-* Action Features:: Special features for use in actions.
-* Internationalization:: How to let the parser speak in the user's
- native language.
-@end menu
+@smallexample
+namespace foo @{ namespace bar @{
+ class position;
+ class location;
+@} @}
+@end smallexample
-@node Parser Function
-@section The Parser Function @code{yyparse}
-@findex yyparse
+@item Accepted Values:
+Any absolute or relative C++ namespace reference without a trailing
+@code{"::"}. For example, @code{"foo"} or @code{"::foo::bar"}.
-You call the function @code{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 @code{yyparse} to return immediately
-without reading further.
+@item Default Value:
+The value specified by @code{%name-prefix}, which defaults to @code{yy}.
+This usage of @code{%name-prefix} is for backward compatibility and can
+be confusing since @code{%name-prefix} also specifies the textual prefix
+for the lexical analyzer function. Thus, if you specify
+@code{%name-prefix}, it is best to also specify @samp{%define
+api.namespace} so that @code{%name-prefix} @emph{only} affects the
+lexical analyzer function. For example, if you specify:
+@smallexample
+%define api.namespace "foo"
+%name-prefix "bar::"
+@end smallexample
-@deftypefun int yyparse (void)
-The value returned by @code{yyparse} is 0 if parsing was successful (return
-is due to end-of-input).
+The parser namespace is @code{foo} and @code{yylex} is referenced as
+@code{bar::lex}.
+@end itemize
+@c namespace
-The value is 1 if parsing failed because of invalid input, i.e., input
-that contains a syntax error or that causes @code{YYABORT} to be
-invoked.
-The value is 2 if parsing failed due to memory exhaustion.
-@end deftypefun
-In an action, you can cause immediate return from @code{yyparse} by using
-these macros:
+@c ================================================== api.pure
+@item api.pure
+@findex %define api.pure
-@defmac YYACCEPT
-@findex YYACCEPT
-Return immediately with value 0 (to report success).
-@end defmac
+@itemize @bullet
+@item Language(s): C
-@defmac YYABORT
-@findex YYABORT
-Return immediately with value 1 (to report failure).
-@end defmac
+@item Purpose: Request a pure (reentrant) parser program.
+@xref{Pure Decl, ,A Pure (Reentrant) Parser}.
-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 @code{%parse-param}:
+@item Accepted Values: Boolean
-@deffn {Directive} %parse-param @{@var{argument-declaration}@}
-@findex %parse-param
-Declare that an argument declared by the braced-code
-@var{argument-declaration} is an additional @code{yyparse} argument.
-The @var{argument-declaration} is used when declaring
-functions or prototypes. The last identifier in
-@var{argument-declaration} must be the argument name.
-@end deffn
+@item Default Value: @code{false}
+@end itemize
+@c api.pure
-Here's an example. Write this in the parser:
-@example
-%parse-param @{int *nastiness@}
-%parse-param @{int *randomness@}
-@end example
-@noindent
-Then call the parser like this:
+@c ================================================== api.push-pull
+@item api.push-pull
+@findex %define api.push-pull
-@example
-@{
- int nastiness, randomness;
- @dots{} /* @r{Store proper data in @code{nastiness} and @code{randomness}.} */
- value = yyparse (&nastiness, &randomness);
- @dots{}
-@}
-@end example
+@itemize @bullet
+@item Language(s): C (deterministic parsers only)
-@noindent
-In the grammar actions, use expressions like this to refer to the data:
+@item Purpose: Requests a pull parser, a push parser, or both.
+@xref{Push Decl, ,A Push Parser}.
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+
+@item Accepted Values: @code{pull}, @code{push}, @code{both}
+
+@item Default Value: @code{pull}
+@end itemize
+@c api.push-pull
+
+@item api.tokens.prefix
+@findex %define api.tokens.prefix
+
+@itemize
+@item Languages(s): all
+
+@item Purpose:
+Add a prefix to the token names when generating their definition in the
+target language. For instance
@example
-exp: @dots{} @{ @dots{}; *randomness += 1; @dots{} @}
+%token FILE for ERROR
+%define api.tokens.prefix "TOK_"
+%%
+start: FILE for ERROR;
@end example
+@noindent
+generates the definition of the symbols @code{TOK_FILE}, @code{TOK_for},
+and @code{TOK_ERROR} in the generated source files. In particular, the
+scanner must use these prefixed token names, while the grammar itself
+may still use the short names (as in the sample rule given above). The
+generated informational files (@file{*.output}, @file{*.xml},
+@file{*.dot}) are not modified by this prefix. See @ref{Calc++ Parser}
+and @ref{Calc++ Scanner}, for a complete example.
+
+@item Accepted Values:
+Any string. Should be a valid identifier prefix in the target language,
+in other words, it should typically be an identifier itself (sequence of
+letters, underscores, and ---not at the beginning--- digits).
+
+@item Default Value:
+empty
+@end itemize
+@c api.tokens.prefix
-@node Lexical
-@section The Lexical Analyzer Function @code{yylex}
-@findex yylex
-@cindex lexical analyzer
-The @dfn{lexical analyzer} function, @code{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 @code{yyparse} can
-call it. The function is sometimes referred to as a lexical scanner.
+@item lr.default-reductions
+@cindex default reductions
+@findex %define lr.default-reductions
+@cindex delayed syntax errors
+@cindex syntax errors delayed
-In simple programs, @code{yylex} is often defined at the end of the Bison
-grammar file. If @code{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 @samp{-d} option when you run Bison, so that it will
-write these macro definitions into a separate header file
-@file{@var{name}.tab.h} which you can include in the other source files
-that need it. @xref{Invocation, ,Invoking Bison}.
+@itemize @bullet
+@item Language(s): all
+
+@item Purpose: Specifies the kind of states that are permitted to
+contain default reductions.
+That is, in such a state, Bison declares the reduction with the largest
+lookahead set to be the default reduction and then removes that
+lookahead set.
+The advantages of default reductions are discussed below.
+The disadvantage is that, when the generated parser encounters a
+syntactically unacceptable token, the parser might then perform
+unnecessary default reductions before it can detect the syntax error.
+
+(This feature is experimental.
+More user feedback will help to stabilize it.)
+
+@item Accepted Values:
+@itemize
+@item @code{all}.
+For @acronym{LALR} and @acronym{IELR} parsers (@pxref{Decl
+Summary,,lr.type}) by default, all states are permitted to contain
+default reductions.
+The advantage is that parser table sizes can be significantly reduced.
+The reason Bison does not by default attempt to address the disadvantage
+of delayed syntax error detection is that this disadvantage is already
+inherent in @acronym{LALR} and @acronym{IELR} parser tables.
+That is, unlike in a canonical @acronym{LR} state, the lookahead sets of
+reductions in an @acronym{LALR} or @acronym{IELR} state can contain
+tokens that are syntactically incorrect for some left contexts.
+
+@item @code{consistent}.
+@cindex consistent states
+A consistent state is a state that has only one possible action.
+If that action is a reduction, then the parser does not need to request
+a lookahead token from the scanner before performing that action.
+However, the parser only recognizes the ability to ignore the lookahead
+token when such a reduction is encoded as a default reduction.
+Thus, if default reductions are permitted in and only in consistent
+states, then a canonical @acronym{LR} parser reports a syntax error as
+soon as it @emph{needs} the syntactically unacceptable token from the
+scanner.
+
+@item @code{accepting}.
+@cindex accepting state
+By default, the only default reduction permitted in a canonical
+@acronym{LR} parser is the accept action in the accepting state, which
+the parser reaches only after reading all tokens from the input.
+Thus, the default canonical @acronym{LR} parser reports a syntax error
+as soon as it @emph{reaches} the syntactically unacceptable token
+without performing any extra reductions.
+@end itemize
-@menu
-* Calling Convention:: How @code{yyparse} calls @code{yylex}.
-* Token Values:: How @code{yylex} must return the semantic value
- of the token it has read.
-* Token Locations:: How @code{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 (@pxref{Pure Decl, ,A Pure (Reentrant) Parser}).
-@end menu
+@item Default Value:
+@itemize
+@item @code{accepting} if @code{lr.type} is @code{canonical-lr}.
+@item @code{all} otherwise.
+@end itemize
+@end itemize
-@node Calling Convention
-@subsection Calling Convention for @code{yylex}
+@item lr.keep-unreachable-states
+@findex %define lr.keep-unreachable-states
-The value that @code{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.
+@itemize @bullet
+@item Language(s): all
-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 @code{yylex} can use the name
-to indicate that type. @xref{Symbols}.
+@item 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.
-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 @code{yylex} can simply return that character code, possibly converted
-to @code{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.
+@item Accepted Values: Boolean
-Here is an example showing these things:
+@item Default Value: @code{false}
-@example
-int
-yylex (void)
-@{
- @dots{}
- if (c == EOF) /* Detect end-of-input. */
- return 0;
- @dots{}
- if (c == '+' || c == '-')
- return c; /* Assume token type for `+' is '+'. */
- @dots{}
- return INT; /* Return the type of the token. */
- @dots{}
-@}
-@end example
+@item Caveats:
-@noindent
-This interface has been designed so that the output from the @code{lex}
-utility can be used without change as the definition of @code{yylex}.
+@itemize @bullet
-If the grammar uses literal string tokens, there are two ways that
-@code{yylex} can determine the token type codes for them:
+@item 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.
+
+@item 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.
+@end itemize
+@end itemize
+@c lr.keep-unreachable-states
+
+@item lr.type
+@findex %define lr.type
+@cindex @acronym{LALR}
+@cindex @acronym{IELR}
+@cindex @acronym{LR}
@itemize @bullet
-@item
-If the grammar defines symbolic token names as aliases for the
-literal string tokens, @code{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 @code{yylex}.
+@item Language(s): all
-@item
-@code{yylex} can find the multicharacter token in the @code{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 @code{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.
+@item Purpose: Specifies the type of parser tables within the
+@acronym{LR}(1) family.
+(This feature is experimental.
+More user feedback will help to stabilize it.)
-Here's code for looking up a multicharacter token in @code{yytname},
-assuming that the characters of the token are stored in
-@code{token_buffer}, and assuming that the token does not contain any
-characters like @samp{"} that require escaping.
+@item Accepted Values:
+@itemize
+@item @code{lalr}.
+While Bison generates @acronym{LALR} parser tables by default for
+historical reasons, @acronym{IELR} or canonical @acronym{LR} is almost
+always preferable for deterministic parsers.
+The trouble is that @acronym{LALR} parser tables can suffer from
+mysterious conflicts and thus may not accept the full set of sentences
+that @acronym{IELR} and canonical @acronym{LR} accept.
+@xref{Mystery Conflicts}, for details.
+However, there are at least two scenarios where @acronym{LALR} may be
+worthwhile:
+@itemize
+@cindex @acronym{GLR} with @acronym{LALR}
+@item When employing @acronym{GLR} parsers (@pxref{GLR Parsers}), if you
+do not resolve any conflicts statically (for example, with @code{%left}
+or @code{%prec}), then the parser explores all potential parses of any
+given input.
+In this case, the use of @acronym{LALR} parser tables is guaranteed not
+to alter the language accepted by the parser.
+@acronym{LALR} parser tables are the smallest parser tables Bison can
+currently generate, so they may be preferable.
+
+@item Occasionally during development, an especially malformed grammar
+with a major recurring flaw may severely impede the @acronym{IELR} or
+canonical @acronym{LR} parser table generation algorithm.
+@acronym{LALR} can be a quick way to generate parser tables in order to
+investigate such problems while ignoring the more subtle differences
+from @acronym{IELR} and canonical @acronym{LR}.
+@end itemize
-@smallexample
-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;
- @}
-@end smallexample
+@item @code{ielr}.
+@acronym{IELR} is a minimal @acronym{LR} algorithm.
+That is, given any grammar (@acronym{LR} or non-@acronym{LR}),
+@acronym{IELR} and canonical @acronym{LR} always accept exactly the same
+set of sentences.
+However, as for @acronym{LALR}, the number of parser states is often an
+order of magnitude less for @acronym{IELR} than for canonical
+@acronym{LR}.
+More importantly, because canonical @acronym{LR}'s extra parser states
+may contain duplicate conflicts in the case of non-@acronym{LR}
+grammars, the number of conflicts for @acronym{IELR} is often an order
+of magnitude less as well.
+This can significantly reduce the complexity of developing of a grammar.
+
+@item @code{canonical-lr}.
+@cindex delayed syntax errors
+@cindex syntax errors delayed
+The only advantage of canonical @acronym{LR} over @acronym{IELR} is
+that, for every left context of every canonical @acronym{LR} state, the
+set of tokens accepted by that state is the exact set of tokens that is
+syntactically acceptable in that left context.
+Thus, the only difference in parsing behavior is that the canonical
+@acronym{LR} parser can report a syntax error as soon as possible
+without performing any unnecessary reductions.
+@xref{Decl Summary,,lr.default-reductions}, for further details.
+Even when canonical @acronym{LR} behavior is ultimately desired,
+@acronym{IELR}'s elimination of duplicate conflicts should still
+facilitate the development of a grammar.
+@end itemize
-The @code{yytname} table is generated only if you use the
-@code{%token-table} declaration. @xref{Decl Summary}.
+@item Default Value: @code{lalr}
@end itemize
-@node Token Values
-@subsection Semantic Values of Tokens
-@vindex yylval
-In an ordinary (nonreentrant) parser, the semantic value of the token must
-be stored into the global variable @code{yylval}. When you are using
-just one data type for semantic values, @code{yylval} has that type.
-Thus, if the type is @code{int} (the default), you might write this in
-@code{yylex}:
+@c ================================================== namespace
+@item namespace
+@findex %define namespace
+Obsoleted by @code{api.namespace}
+@c namespace
-@example
-@group
- @dots{}
- yylval = value; /* Put value onto Bison stack. */
- return INT; /* Return the type of the token. */
- @dots{}
-@end group
-@end example
-When you are using multiple data types, @code{yylval}'s type is a union
-made from the @code{%union} declaration (@pxref{Union Decl, ,The
-Collection of Value Types}). So when you store a token's value, you
-must use the proper member of the union. If the @code{%union}
-declaration looks like this:
+@c ================================================== parse.assert
+@item parse.assert
+@findex %define parse.assert
-@example
-@group
-%union @{
- int intval;
- double val;
- symrec *tptr;
-@}
-@end group
-@end example
+@itemize
+@item Languages(s): C++
-@noindent
-then the code in @code{yylex} might look like this:
+@item Purpose: Issue runtime assertions to catch invalid uses.
+In C++, when variants are used, symbols must be constructed and
+destroyed properly. This option checks these constraints.
-@example
-@group
- @dots{}
- yylval.intval = value; /* Put value onto Bison stack. */
- return INT; /* Return the type of the token. */
- @dots{}
-@end group
-@end example
+@item Accepted Values: Boolean
-@node Token Locations
-@subsection Textual Locations of Tokens
+@item Default Value: @code{false}
+@end itemize
+@c parse.assert
-@vindex yylloc
-If you are using the @samp{@@@var{n}}-feature (@pxref{Locations, ,
-Tracking Locations}) in actions to keep track of the textual locations
-of tokens and groupings, then you must provide this information in
-@code{yylex}. The function @code{yyparse} expects to find the textual
-location of a token just parsed in the global variable @code{yylloc}.
-So @code{yylex} must store the proper data in that variable.
-By default, the value of @code{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 @code{first_line}, @code{first_column},
-@code{last_line} and @code{last_column}. Note that the use of this
-feature makes the parser noticeably slower.
+@c ================================================== parse.error
+@item parse.error
+@findex %define parse.error
+@itemize
+@item Languages(s):
+all.
+@item Purpose:
+Control the kind of error messages passed to the error reporting
+function. @xref{Error Reporting, ,The Error Reporting Function
+@code{yyerror}}.
+@item Accepted Values:
+@itemize
+@item @code{simple}
+Error messages passed to @code{yyerror} are simply @w{@code{"syntax
+error"}}.
+@item @code{verbose}
+Error messages report the unexpected token, and possibly the expected
+ones.
+@end itemize
-@tindex YYLTYPE
-The data type of @code{yylloc} has the name @code{YYLTYPE}.
+@item Default Value:
+@code{simple}
+@end itemize
+@c parse.error
-@node Pure Calling
-@subsection Calling Conventions for Pure Parsers
-When you use the Bison declaration @code{%pure-parser} to request a
-pure, reentrant parser, the global communication variables @code{yylval}
-and @code{yylloc} cannot be used. (@xref{Pure Decl, ,A Pure (Reentrant)
-Parser}.) In such parsers the two global variables are replaced by
-pointers passed as arguments to @code{yylex}. You must declare them as
-shown here, and pass the information back by storing it through those
-pointers.
+@c ================================================== parse.trace
+@item parse.trace
+@findex %define parse.trace
-@example
-int
-yylex (YYSTYPE *lvalp, YYLTYPE *llocp)
-@{
- @dots{}
- *lvalp = value; /* Put value onto Bison stack. */
- return INT; /* Return the type of the token. */
- @dots{}
-@}
-@end example
+@itemize
+@item Languages(s): C, C++
-If the grammar file does not use the @samp{@@} constructs to refer to
-textual locations, then the type @code{YYLTYPE} will not be defined. In
-this case, omit the second argument; @code{yylex} will be called with
-only one argument.
+@item Purpose: Require parser instrumentation for tracing.
+In C/C++, define the macro @code{YYDEBUG} to 1 in the parser file if it
+is not already defined, so that the debugging facilities are compiled.
+@xref{Tracing, ,Tracing Your Parser}.
+@item Accepted Values: Boolean
-If you wish to pass the additional parameter data to @code{yylex}, use
-@code{%lex-param} just like @code{%parse-param} (@pxref{Parser
-Function}).
+@item Default Value: @code{false}
+@end itemize
+@c parse.trace
-@deffn {Directive} lex-param @{@var{argument-declaration}@}
-@findex %lex-param
-Declare that the braced-code @var{argument-declaration} is an
-additional @code{yylex} argument declaration.
+@end table
@end deffn
+@c ---------------------------------------------------------- %define
-For instance:
-
-@example
-%parse-param @{int *nastiness@}
-%lex-param @{int *nastiness@}
-%parse-param @{int *randomness@}
-@end example
+@deffn {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 @file{@var{name}.c} then this file
+is named @file{@var{name}.h}.
-@noindent
-results in the following signature:
+For C parsers, the output header declares @code{YYSTYPE} unless
+@code{YYSTYPE} is already defined as a macro or you have used a
+@code{<@var{type}>} tag without using @code{%union}.
+Therefore, if you are using a @code{%union}
+(@pxref{Multiple Types, ,More Than One Value Type}) with components that
+require other definitions, or if you have defined a @code{YYSTYPE} macro
+or type definition
+(@pxref{Value Type, ,Data Types of Semantic Values}), 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 @code{YYSTYPE}.
-@example
-int yylex (int *nastiness);
-int yyparse (int *nastiness, int *randomness);
-@end example
+Unless your parser is pure, the output header declares @code{yylval}
+as an external variable. @xref{Pure Decl, ,A Pure (Reentrant)
+Parser}.
-If @code{%pure-parser} is added:
+If you have also used locations, the output header declares
+@code{YYLTYPE} and @code{yylloc} using a protocol similar to that of
+the @code{YYSTYPE} macro and @code{yylval}. @xref{Locations, ,Tracking
+Locations}.
-@example
-int yylex (YYSTYPE *lvalp, int *nastiness);
-int yyparse (int *nastiness, int *randomness);
-@end example
+This output file is normally essential if you wish to put the definition
+of @code{yylex} in a separate source file, because @code{yylex}
+typically needs to be able to refer to the above-mentioned declarations
+and to the token type codes. @xref{Token Values, ,Semantic Values of
+Tokens}.
-@noindent
-and finally, if both @code{%pure-parser} and @code{%locations} are used:
+@findex %code requires
+@findex %code provides
+If you have declared @code{%code requires} or @code{%code provides}, the output
+header also contains their code.
+@xref{Decl Summary, ,%code}.
+@end deffn
-@example
-int yylex (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
-int yyparse (int *nastiness, int *randomness);
-@end example
+@deffn {Directive} %defines @var{defines-file}
+Same as above, but save in the file @var{defines-file}.
+@end deffn
-@node Error Reporting
-@section The Error Reporting Function @code{yyerror}
-@cindex error reporting function
-@findex yyerror
-@cindex parse error
-@cindex syntax error
+@deffn {Directive} %destructor
+Specify how the parser should reclaim the memory associated to
+discarded symbols. @xref{Destructor Decl, , Freeing Discarded Symbols}.
+@end deffn
-The Bison parser detects a @dfn{syntax error} or @dfn{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 @code{YYERROR} (@pxref{Action Features, ,Special Features for Use
-in Actions}).
+@deffn {Directive} %file-prefix "@var{prefix}"
+Specify a prefix to use for all Bison output file names. The names are
+chosen as if the input file were named @file{@var{prefix}.y}.
+@end deffn
-The Bison parser expects to report the error by calling an error
-reporting function named @code{yyerror}, which you must supply. It is
-called by @code{yyparse} whenever a syntax error is found, and it
-receives one argument. For a syntax error, the string is normally
-@w{@code{"syntax error"}}.
+@deffn {Directive} %language "@var{language}"
+Specify the programming language for the generated parser. Currently
+supported languages include C, C++, and Java.
+@var{language} is case-insensitive.
-@findex %error-verbose
-If you invoke the directive @code{%error-verbose} in the Bison
-declarations section (@pxref{Bison Declarations, ,The Bison Declarations
-Section}), then Bison provides a more verbose and specific error message
-string instead of just plain @w{@code{"syntax error"}}.
+This directive is experimental and its effect may be modified in future
+releases.
+@end deffn
-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, @code{yyparse} calls @code{yyerror} in the usual
-fashion, except that the argument string is @w{@code{"memory exhausted"}}.
+@deffn {Directive} %locations
+Generate the code processing the locations (@pxref{Action Features,
+,Special Features for Use in Actions}). This mode is enabled as soon as
+the grammar uses the special @samp{@@@var{n}} tokens, but if your
+grammar does not use it, using @samp{%locations} allows for more
+accurate syntax error messages.
+@end deffn
-In some cases diagnostics like @w{@code{"syntax error"}} are
-translated automatically from English to some other language before
-they are passed to @code{yyerror}. @xref{Internationalization}.
+@deffn {Directive} %name-prefix "@var{prefix}"
+Rename the external symbols used in the parser so that they start with
+@var{prefix} instead of @samp{yy}. The precise list of symbols renamed
+in C parsers
+is @code{yyparse}, @code{yylex}, @code{yyerror}, @code{yynerrs},
+@code{yylval}, @code{yychar}, @code{yydebug}, and
+(if locations are used) @code{yylloc}. If you use a push parser,
+@code{yypush_parse}, @code{yypull_parse}, @code{yypstate},
+@code{yypstate_new} and @code{yypstate_delete} will
+also be renamed. For example, if you use @samp{%name-prefix "c_"}, the
+names become @code{c_parse}, @code{c_lex}, and so on.
+For C++ parsers, see the @samp{%define api.namespace} documentation in this
+section.
+@xref{Multiple Parsers, ,Multiple Parsers in the Same Program}.
+@end deffn
-The following definition suffices in simple programs:
+@ifset defaultprec
+@deffn {Directive} %no-default-prec
+Do not assign a precedence to rules lacking an explicit @code{%prec}
+modifier (@pxref{Contextual Precedence, ,Context-Dependent
+Precedence}).
+@end deffn
+@end ifset
-@example
-@group
-void
-yyerror (char const *s)
-@{
-@end group
-@group
- fprintf (stderr, "%s\n", s);
-@}
-@end group
-@end example
+@deffn {Directive} %no-lines
+Don't generate any @code{#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.
+@end deffn
-After @code{yyerror} returns to @code{yyparse}, the latter will attempt
-error recovery if you have written suitable error recovery grammar rules
-(@pxref{Error Recovery}). If recovery is impossible, @code{yyparse} will
-immediately return 1.
+@deffn {Directive} %output "@var{file}"
+Specify @var{file} for the parser file.
+@end deffn
-Obviously, in location tracking pure parsers, @code{yyerror} should have
-an access to the current location.
-This is indeed the case for the @acronym{GLR}
-parsers, but not for the Yacc parser, for historical reasons. I.e., if
-@samp{%locations %pure-parser} is passed then the prototypes for
-@code{yyerror} are:
+@deffn {Directive} %pure-parser
+Deprecated version of @samp{%define api.pure} (@pxref{Decl Summary, ,%define}),
+for which Bison is more careful to warn about unreasonable usage.
+@end deffn
-@example
-void yyerror (char const *msg); /* Yacc parsers. */
-void yyerror (YYLTYPE *locp, char const *msg); /* GLR parsers. */
-@end example
+@deffn {Directive} %require "@var{version}"
+Require version @var{version} or higher of Bison. @xref{Require Decl, ,
+Require a Version of Bison}.
+@end deffn
-If @samp{%parse-param @{int *nastiness@}} is used, then:
+@deffn {Directive} %skeleton "@var{file}"
+Specify the skeleton to use.
+
+@c You probably don't need this option unless you are developing Bison.
+@c You should use @code{%language} if you want to specify the skeleton for a
+@c different language, because it is clearer and because it will always choose the
+@c correct skeleton for non-deterministic or push parsers.
+
+If @var{file} does not contain a @code{/}, @var{file} is the name of a skeleton
+file in the Bison installation directory.
+If it does, @var{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.
+@end deffn
-@example
-void yyerror (int *nastiness, char const *msg); /* Yacc parsers. */
-void yyerror (int *nastiness, char const *msg); /* GLR parsers. */
-@end example
+@deffn {Directive} %token-table
+Generate an array of token names in the parser file. The name of the
+array is @code{yytname}; @code{yytname[@var{i}]} is the name of the
+token whose internal Bison token code number is @var{i}. The first
+three elements of @code{yytname} correspond to the predefined tokens
+@code{"$end"},
+@code{"error"}, and @code{"$undefined"}; after these come the symbols
+defined in the grammar file.
-Finally, @acronym{GLR} and Yacc parsers share the same @code{yyerror} calling
-convention for absolutely pure parsers, i.e., when the calling
-convention of @code{yylex} @emph{and} the calling convention of
-@code{%pure-parser} are pure. I.e.:
+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
+@code{'+'} corresponds to a three-character name, represented in C as
+@code{"'+'"}; and the Bison two-character literal string @code{"\\/"}
+corresponds to a five-character name, represented in C as
+@code{"\"\\\\/\""}.
-@example
-/* Location tracking. */
-%locations
-/* Pure yylex. */
-%pure-parser
-%lex-param @{int *nastiness@}
-/* Pure yyparse. */
-%parse-param @{int *nastiness@}
-%parse-param @{int *randomness@}
-@end example
+When you specify @code{%token-table}, Bison also generates macro
+definitions for macros @code{YYNTOKENS}, @code{YYNNTS}, and
+@code{YYNRULES}, and @code{YYNSTATES}:
-@noindent
-results in the following signatures for all the parser kinds:
+@table @code
+@item YYNTOKENS
+The highest token number, plus one.
+@item YYNNTS
+The number of nonterminal symbols.
+@item YYNRULES
+The number of grammar rules,
+@item YYNSTATES
+The number of parser states (@pxref{Parser States}).
+@end table
+@end deffn
-@example
-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);
-@end example
+@deffn {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. @xref{Understanding, , Understanding Your Parser}, for more
+information.
+@end deffn
-@noindent
-The prototypes are only indications of how the code produced by Bison
-uses @code{yyerror}. Bison-generated code always ignores the returned
-value, so @code{yyerror} can return any type, including @code{void}.
-Also, @code{yyerror} can be a variadic function; that is why the
-message is always passed last.
+@deffn {Directive} %yacc
+Pretend the option @option{--yacc} was given, i.e., imitate Yacc,
+including its naming conventions. @xref{Bison Options}, for more.
+@end deffn
-Traditionally @code{yyerror} returns an @code{int} that is always
-ignored, but this is purely for historical reasons, and @code{void} is
-preferable since it more accurately describes the return type for
-@code{yyerror}.
-@vindex yynerrs
-The variable @code{yynerrs} contains the number of syntax errors
-reported so far. Normally this variable is global; but if you
-request a pure parser (@pxref{Pure Decl, ,A Pure (Reentrant) Parser})
-then it is a local variable which only the actions can access.
+@node Multiple Parsers
+@section Multiple Parsers in the Same Program
-@node Action Features
-@section Special Features for Use in Actions
-@cindex summary, action features
-@cindex action features summary
+Most programs that use Bison parse only one language and therefore contain
+only one Bison parser. But what if you want to parse more than one
+language with the same program? Then you need to avoid a name conflict
+between different definitions of @code{yyparse}, @code{yylval}, and so on.
-Here is a table of Bison constructs, variables and macros that
-are useful in actions.
+The easy way to do this is to use the option @samp{-p @var{prefix}}
+(@pxref{Invocation, ,Invoking Bison}). This renames the interface
+functions and variables of the Bison parser to start with @var{prefix}
+instead of @samp{yy}. You can use this to give each parser distinct
+names that do not conflict.
-@deffn {Variable} $$
-Acts like a variable that contains the semantic value for the
-grouping made by the current rule. @xref{Actions}.
-@end deffn
+The precise list of symbols renamed is @code{yyparse}, @code{yylex},
+@code{yyerror}, @code{yynerrs}, @code{yylval}, @code{yylloc},
+@code{yychar} and @code{yydebug}. If you use a push parser,
+@code{yypush_parse}, @code{yypull_parse}, @code{yypstate},
+@code{yypstate_new} and @code{yypstate_delete} will also be renamed.
+For example, if you use @samp{-p c}, the names become @code{cparse},
+@code{clex}, and so on.
-@deffn {Variable} $@var{n}
-Acts like a variable that contains the semantic value for the
-@var{n}th component of the current rule. @xref{Actions}.
-@end deffn
+@strong{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, @code{YYSTYPE} is not
+renamed, but defining this in different ways in different parsers causes
+no trouble (@pxref{Value Type, ,Data Types of Semantic Values}).
-@deffn {Variable} $<@var{typealt}>$
-Like @code{$$} but specifies alternative @var{typealt} in the union
-specified by the @code{%union} declaration. @xref{Action Types, ,Data
-Types of Values in Actions}.
-@end deffn
+The @samp{-p} option works by adding macro definitions to the beginning
+of the parser source file, defining @code{yyparse} as
+@code{@var{prefix}parse}, and so on. This effectively substitutes one
+name for the other in the entire parser file.
-@deffn {Variable} $<@var{typealt}>@var{n}
-Like @code{$@var{n}} but specifies alternative @var{typealt} in the
-union specified by the @code{%union} declaration.
-@xref{Action Types, ,Data Types of Values in Actions}.
-@end deffn
+@node Interface
+@chapter Parser C-Language Interface
+@cindex C-language interface
+@cindex interface
-@deffn {Macro} YYABORT;
-Return immediately from @code{yyparse}, indicating failure.
-@xref{Parser Function, ,The Parser Function @code{yyparse}}.
-@end deffn
+The Bison parser is actually a C function named @code{yyparse}. Here we
+describe the interface conventions of @code{yyparse} and the other
+functions that it needs to use.
-@deffn {Macro} YYACCEPT;
-Return immediately from @code{yyparse}, indicating success.
-@xref{Parser Function, ,The Parser Function @code{yyparse}}.
-@end deffn
+Keep in mind that the parser uses many C identifiers starting with
+@samp{yy} and @samp{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.
-@deffn {Macro} YYBACKUP (@var{token}, @var{value});
-@findex YYBACKUP
-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 @acronym{GLR} parsers.
-It installs a lookahead token with token type @var{token} and
-semantic value @var{value}; then it discards the value that was
-going to be reduced by this rule.
+@menu
+* Parser Function:: How to call @code{yyparse} and what it returns.
+* Push Parser Function:: How to call @code{yypush_parse} and what it returns.
+* Pull Parser Function:: How to call @code{yypull_parse} and what it returns.
+* Parser Create Function:: How to call @code{yypstate_new} and what it returns.
+* Parser Delete Function:: How to call @code{yypstate_delete} and what it returns.
+* Lexical:: You must supply a function @code{yylex}
+ which reads tokens.
+* Error Reporting:: You must supply a function @code{yyerror}.
+* Action Features:: Special features for use in actions.
+* Internationalization:: How to let the parser speak in the user's
+ native language.
+@end menu
-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 @samp{cannot back up} and performs ordinary error
-recovery.
+@node Parser Function
+@section The Parser Function @code{yyparse}
+@findex yyparse
-In either case, the rest of the action is not executed.
-@end deffn
+You call the function @code{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 @code{yyparse} to return immediately
+without reading further.
-@deffn {Macro} YYEMPTY
-@vindex YYEMPTY
-Value stored in @code{yychar} when there is no lookahead token.
-@end deffn
-@deffn {Macro} YYEOF
-@vindex YYEOF
-Value stored in @code{yychar} when the lookahead is the end of the input
-stream.
-@end deffn
+@deftypefun int yyparse (void)
+The value returned by @code{yyparse} is 0 if parsing was successful (return
+is due to end-of-input).
-@deffn {Macro} YYERROR;
-@findex 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 @code{yyerror}, and does not print any message. If you
-want to print an error message, call @code{yyerror} explicitly before
-the @samp{YYERROR;} statement. @xref{Error Recovery}.
-@end deffn
+The value is 1 if parsing failed because of invalid input, i.e., input
+that contains a syntax error or that causes @code{YYABORT} to be
+invoked.
-@deffn {Macro} YYRECOVERING
-@findex YYRECOVERING
-The expression @code{YYRECOVERING ()} yields 1 when the parser
-is recovering from a syntax error, and 0 otherwise.
-@xref{Error Recovery}.
-@end deffn
+The value is 2 if parsing failed due to memory exhaustion.
+@end deftypefun
-@deffn {Variable} yychar
-Variable containing either the lookahead token, or @code{YYEOF} when the
-lookahead is the end of the input stream, or @code{YYEMPTY} when no lookahead
-has been performed so the next token is not yet known.
-Do not modify @code{yychar} in a deferred semantic action (@pxref{GLR Semantic
-Actions}).
-@xref{Lookahead, ,Lookahead Tokens}.
-@end deffn
+In an action, you can cause immediate return from @code{yyparse} by using
+these macros:
-@deffn {Macro} yyclearin;
-Discard the current lookahead token. This is useful primarily in
-error rules.
-Do not invoke @code{yyclearin} in a deferred semantic action (@pxref{GLR
-Semantic Actions}).
-@xref{Error Recovery}.
-@end deffn
+@defmac YYACCEPT
+@findex YYACCEPT
+Return immediately with value 0 (to report success).
+@end defmac
-@deffn {Macro} yyerrok;
-Resume generating error messages immediately for subsequent syntax
-errors. This is useful primarily in error rules.
-@xref{Error Recovery}.
-@end deffn
+@defmac YYABORT
+@findex YYABORT
+Return immediately with value 1 (to report failure).
+@end defmac
-@deffn {Variable} yylloc
-Variable containing the lookahead token location when @code{yychar} is not set
-to @code{YYEMPTY} or @code{YYEOF}.
-Do not modify @code{yylloc} in a deferred semantic action (@pxref{GLR Semantic
-Actions}).
-@xref{Actions and Locations, ,Actions and Locations}.
-@end deffn
+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 @code{%parse-param}:
-@deffn {Variable} yylval
-Variable containing the lookahead token semantic value when @code{yychar} is
-not set to @code{YYEMPTY} or @code{YYEOF}.
-Do not modify @code{yylval} in a deferred semantic action (@pxref{GLR Semantic
-Actions}).
-@xref{Actions, ,Actions}.
+@deffn {Directive} %parse-param @{@var{argument-declaration}@}
+@findex %parse-param
+Declare that an argument declared by the braced-code
+@var{argument-declaration} is an additional @code{yyparse} argument.
+The @var{argument-declaration} is used when declaring
+functions or prototypes. The last identifier in
+@var{argument-declaration} must be the argument name.
@end deffn
-@deffn {Value} @@$
-@findex @@$
-Acts like a structure variable containing information on the textual location
-of the grouping made by the current rule. @xref{Locations, ,
-Tracking Locations}.
-
-@c Check if those paragraphs are still useful or not.
+Here's an example. Write this in the parser:
-@c @example
-@c struct @{
-@c int first_line, last_line;
-@c int first_column, last_column;
-@c @};
-@c @end example
+@example
+%parse-param @{int *nastiness@}
+%parse-param @{int *randomness@}
+@end example
-@c Thus, to get the starting line number of the third component, you would
-@c use @samp{@@3.first_line}.
+@noindent
+Then call the parser like this:
-@c In order for the members of this structure to contain valid information,
-@c you must make @code{yylex} supply this information about each token.
-@c If you need only certain members, then @code{yylex} need only fill in
-@c those members.
+@example
+@{
+ int nastiness, randomness;
+ @dots{} /* @r{Store proper data in @code{nastiness} and @code{randomness}.} */
+ value = yyparse (&nastiness, &randomness);
+ @dots{}
+@}
+@end example
-@c The use of this feature makes the parser noticeably slower.
-@end deffn
+@noindent
+In the grammar actions, use expressions like this to refer to the data:
-@deffn {Value} @@@var{n}
-@findex @@@var{n}
-Acts like a structure variable containing information on the textual location
-of the @var{n}th component of the current rule. @xref{Locations, ,
-Tracking Locations}.
-@end deffn
+@example
+exp: @dots{} @{ @dots{}; *randomness += 1; @dots{} @}
+@end example
-@node Internationalization
-@section Parser Internationalization
-@cindex internationalization
-@cindex i18n
-@cindex NLS
-@cindex gettext
-@cindex bison-po
+@node Push Parser Function
+@section The Push Parser Function @code{yypush_parse}
+@findex yypush_parse
-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.
-@xref{Users, , The User's View, gettext, GNU @code{gettext} utilities}.
-For example, the shell command @samp{export LC_ALL=fr_CA.UTF-8} might
-set the user's locale to French Canadian using the @acronym{UTF}-8
-encoding. The exact set of available locales depends on the user's
-installation.
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
-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 @acronym{GNU} Autoconf and
-@acronym{GNU} Automake.
+You call the function @code{yypush_parse} to parse a single token. This
+function is available if either the @samp{%define api.push-pull push} or
+@samp{%define api.push-pull both} declaration is used.
+@xref{Push Decl, ,A Push Parser}.
-@enumerate
-@item
-@cindex bison-i18n.m4
-Into the directory containing the @acronym{GNU} Autoconf macros used
-by the package---often called @file{m4}---copy the
-@file{bison-i18n.m4} file installed by Bison under
-@samp{share/aclocal/bison-i18n.m4} in Bison's installation directory.
-For example:
+@deftypefun int yypush_parse (yypstate *yyps)
+The value returned by @code{yypush_parse} is the same as for yyparse with the
+following exception. @code{yypush_parse} will return YYPUSH_MORE if more input
+is required to finish parsing the grammar.
+@end deftypefun
-@example
-cp /usr/local/share/aclocal/bison-i18n.m4 m4/bison-i18n.m4
-@end example
+@node Pull Parser Function
+@section The Pull Parser Function @code{yypull_parse}
+@findex yypull_parse
-@item
-@findex BISON_I18N
-@vindex BISON_LOCALEDIR
-@vindex YYENABLE_NLS
-In the top-level @file{configure.ac}, after the @code{AM_GNU_GETTEXT}
-invocation, add an invocation of @code{BISON_I18N}. This macro is
-defined in the file @file{bison-i18n.m4} that you copied earlier. It
-causes @samp{configure} to find the value of the
-@code{BISON_LOCALEDIR} variable, and it defines the source-language
-symbol @code{YYENABLE_NLS} to enable translations in the
-Bison-generated parser.
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
-@item
-In the @code{main} function of your program, designate the directory
-containing Bison's runtime message catalog, through a call to
-@samp{bindtextdomain} with domain name @samp{bison-runtime}.
-For example:
+You call the function @code{yypull_parse} to parse the rest of the input
+stream. This function is available if the @samp{%define api.push-pull both}
+declaration is used.
+@xref{Push Decl, ,A Push Parser}.
-@example
-bindtextdomain ("bison-runtime", BISON_LOCALEDIR);
-@end example
+@deftypefun int yypull_parse (yypstate *yyps)
+The value returned by @code{yypull_parse} is the same as for @code{yyparse}.
+@end deftypefun
-Typically this appears after any other call @code{bindtextdomain
-(PACKAGE, LOCALEDIR)} that your package already has. Here we rely on
-@samp{BISON_LOCALEDIR} to be defined as a string through the
-@file{Makefile}.
+@node Parser Create Function
+@section The Parser Create Function @code{yystate_new}
+@findex yypstate_new
-@item
-In the @file{Makefile.am} that controls the compilation of the @code{main}
-function, make @samp{BISON_LOCALEDIR} available as a C preprocessor macro,
-either in @samp{DEFS} or in @samp{AM_CPPFLAGS}. For example:
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
-@example
-DEFS = @@DEFS@@ -DBISON_LOCALEDIR='"$(BISON_LOCALEDIR)"'
-@end example
+You call the function @code{yypstate_new} to create a new parser instance.
+This function is available if either the @samp{%define api.push-pull push} or
+@samp{%define api.push-pull both} declaration is used.
+@xref{Push Decl, ,A Push Parser}.
-or:
+@deftypefun 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.
+@end deftypefun
-@example
-AM_CPPFLAGS = -DBISON_LOCALEDIR='"$(BISON_LOCALEDIR)"'
-@end example
+@node Parser Delete Function
+@section The Parser Delete Function @code{yystate_delete}
+@findex yypstate_delete
-@item
-Finally, invoke the command @command{autoreconf} to generate the build
-infrastructure.
-@end enumerate
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+You call the function @code{yypstate_delete} to delete a parser instance.
+function is available if either the @samp{%define api.push-pull push} or
+@samp{%define api.push-pull both} declaration is used.
+@xref{Push Decl, ,A Push Parser}.
-@node Algorithm
-@chapter The Bison Parser Algorithm
-@cindex Bison parser algorithm
-@cindex algorithm of parser
-@cindex shifting
-@cindex reduction
-@cindex parser stack
-@cindex stack, parser
+@deftypefun 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.
+@end deftypefun
-As Bison reads tokens, it pushes them onto a stack along with their
-semantic values. The stack is called the @dfn{parser stack}. Pushing a
-token is traditionally called @dfn{shifting}.
+@node Lexical
+@section The Lexical Analyzer Function @code{yylex}
+@findex yylex
+@cindex lexical analyzer
-For example, suppose the infix calculator has read @samp{1 + 5 *}, with a
-@samp{3} to come. The stack will have four elements, one for each token
-that was shifted.
+The @dfn{lexical analyzer} function, @code{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 @code{yyparse} can
+call it. The function is sometimes referred to as a lexical scanner.
-But the stack does not always have an element for each token read. When
-the last @var{n} tokens and groupings shifted match the components of a
-grammar rule, they can be combined according to that rule. This is called
-@dfn{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.
+In simple programs, @code{yylex} is often defined at the end of the Bison
+grammar file. If @code{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 @samp{-d} option when you run Bison, so that it will
+write these macro definitions into a separate header file
+@file{@var{name}.tab.h} which you can include in the other source files
+that need it. @xref{Invocation, ,Invoking Bison}.
-For example, if the infix calculator's parser stack contains this:
+@menu
+* Calling Convention:: How @code{yyparse} calls @code{yylex}.
+* Token Values:: How @code{yylex} must return the semantic value
+ of the token it has read.
+* Token Locations:: How @code{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
+ (@pxref{Pure Decl, ,A Pure (Reentrant) Parser}).
+@end menu
-@example
-1 + 5 * 3
-@end example
+@node Calling Convention
+@subsection Calling Convention for @code{yylex}
-@noindent
-and the next input token is a newline character, then the last three
-elements can be reduced to 15 via the rule:
+The value that @code{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.
-@example
-expr: expr '*' expr;
-@end example
+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 @code{yylex} can use the name
+to indicate that type. @xref{Symbols}.
-@noindent
-Then the stack contains just these three elements:
+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 @code{yylex} can simply return that character code, possibly converted
+to @code{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:
@example
-1 + 15
+int
+yylex (void)
+@{
+ @dots{}
+ if (c == EOF) /* Detect end-of-input. */
+ return 0;
+ @dots{}
+ if (c == '+' || c == '-')
+ return c; /* Assume token type for `+' is '+'. */
+ @dots{}
+ return INT; /* Return the type of the token. */
+ @dots{}
+@}
@end example
@noindent
-At this point, another reduction can be made, resulting in the single value
-16. Then the newline token can be shifted.
+This interface has been designed so that the output from the @code{lex}
+utility can be used without change as the definition of @code{yylex}.
-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
-(@pxref{Language and Grammar, ,Languages and Context-Free Grammars}).
+If the grammar uses literal string tokens, there are two ways that
+@code{yylex} can determine the token type codes for them:
-This kind of parser is known in the literature as a bottom-up parser.
+@itemize @bullet
+@item
+If the grammar defines symbolic token names as aliases for the
+literal string tokens, @code{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 @code{yylex}.
-@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.
-@end menu
+@item
+@code{yylex} can find the multicharacter token in the @code{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 @code{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.
-@node Lookahead
-@section Lookahead Tokens
-@cindex lookahead token
+Here's code for looking up a multicharacter token in @code{yytname},
+assuming that the characters of the token are stored in
+@code{token_buffer}, and assuming that the token does not contain any
+characters like @samp{"} that require escaping.
-The Bison parser does @emph{not} always reduce immediately as soon as the
-last @var{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.
+@smallexample
+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;
+ @}
+@end smallexample
-When a token is read, it is not immediately shifted; first it becomes the
-@dfn{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.
+The @code{yytname} table is generated only if you use the
+@code{%token-table} declaration. @xref{Decl Summary}.
+@end itemize
-Here is a simple case where lookahead is needed. These three rules define
-expressions which contain binary addition operators and postfix unary
-factorial operators (@samp{!}), and allow parentheses for grouping.
+@node Token Values
+@subsection Semantic Values of Tokens
+
+@vindex yylval
+In an ordinary (nonreentrant) parser, the semantic value of the token must
+be stored into the global variable @code{yylval}. When you are using
+just one data type for semantic values, @code{yylval} has that type.
+Thus, if the type is @code{int} (the default), you might write this in
+@code{yylex}:
@example
@group
-expr: term '+' expr
- | term
- ;
+ @dots{}
+ yylval = value; /* Put value onto Bison stack. */
+ return INT; /* Return the type of the token. */
+ @dots{}
@end group
+@end example
-@group
-term: '(' expr ')'
- | term '!'
- | NUMBER
- ;
+When you are using multiple data types, @code{yylval}'s type is a union
+made from the @code{%union} declaration (@pxref{Union Decl, ,The
+Collection of Value Types}). So when you store a token's value, you
+must use the proper member of the union. If the @code{%union}
+declaration looks like this:
+
+@example
+@group
+%union @{
+ int intval;
+ double val;
+ symrec *tptr;
+@}
@end group
@end example
-Suppose that the tokens @w{@samp{1 + 2}} have been read and shifted; what
-should be done? If the following token is @samp{)}, then the first three
-tokens must be reduced to form an @code{expr}. This is the only valid
-course, because shifting the @samp{)} would produce a sequence of symbols
-@w{@code{term ')'}}, and no rule allows this.
+@noindent
+then the code in @code{yylex} might look like this:
-If the following token is @samp{!}, then it must be shifted immediately so
-that @w{@samp{2 !}} can be reduced to make a @code{term}. If instead the
-parser were to reduce before shifting, @w{@samp{1 + 2}} would become an
-@code{expr}. It would then be impossible to shift the @samp{!} because
-doing so would produce on the stack the sequence of symbols @code{expr
-'!'}. No rule allows that sequence.
+@example
+@group
+ @dots{}
+ yylval.intval = value; /* Put value onto Bison stack. */
+ return INT; /* Return the type of the token. */
+ @dots{}
+@end group
+@end example
+
+@node Token Locations
+@subsection Textual Locations of Tokens
-@vindex yychar
-@vindex yylval
@vindex yylloc
-The lookahead token is stored in the variable @code{yychar}.
-Its semantic value and location, if any, are stored in the variables
-@code{yylval} and @code{yylloc}.
-@xref{Action Features, ,Special Features for Use in Actions}.
+If you are using the @samp{@@@var{n}}-feature (@pxref{Locations, ,
+Tracking Locations}) in actions to keep track of the textual locations
+of tokens and groupings, then you must provide this information in
+@code{yylex}. The function @code{yyparse} expects to find the textual
+location of a token just parsed in the global variable @code{yylloc}.
+So @code{yylex} must store the proper data in that variable.
-@node Shift/Reduce
-@section Shift/Reduce Conflicts
-@cindex conflicts
-@cindex shift/reduce conflicts
-@cindex dangling @code{else}
-@cindex @code{else}, dangling
+By default, the value of @code{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 @code{first_line}, @code{first_column},
+@code{last_line} and @code{last_column}. Note that the use of this
+feature makes the parser noticeably slower.
-Suppose we are parsing a language which has if-then and if-then-else
-statements, with a pair of rules like this:
+@tindex YYLTYPE
+The data type of @code{yylloc} has the name @code{YYLTYPE}.
+
+@node Pure Calling
+@subsection Calling Conventions for Pure Parsers
+
+When you use the Bison declaration @samp{%define api.pure} to request a
+pure, reentrant parser, the global communication variables @code{yylval}
+and @code{yylloc} cannot be used. (@xref{Pure Decl, ,A Pure (Reentrant)
+Parser}.) In such parsers the two global variables are replaced by
+pointers passed as arguments to @code{yylex}. You must declare them as
+shown here, and pass the information back by storing it through those
+pointers.
@example
-@group
-if_stmt:
- IF expr THEN stmt
- | IF expr THEN stmt ELSE stmt
- ;
-@end group
+int
+yylex (YYSTYPE *lvalp, YYLTYPE *llocp)
+@{
+ @dots{}
+ *lvalp = value; /* Put value onto Bison stack. */
+ return INT; /* Return the type of the token. */
+ @dots{}
+@}
@end example
-@noindent
-Here we assume that @code{IF}, @code{THEN} and @code{ELSE} are
-terminal symbols for specific keyword tokens.
+If the grammar file does not use the @samp{@@} constructs to refer to
+textual locations, then the type @code{YYLTYPE} will not be defined. In
+this case, omit the second argument; @code{yylex} will be called with
+only one argument.
-When the @code{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
-@code{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 @dfn{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.
+If you wish to pass the additional parameter data to @code{yylex}, use
+@code{%lex-param} just like @code{%parse-param} (@pxref{Parser
+Function}).
-Since the parser prefers to shift the @code{ELSE}, the result is to attach
-the else-clause to the innermost if-statement, making these two inputs
-equivalent:
+@deffn {Directive} lex-param @{@var{argument-declaration}@}
+@findex %lex-param
+Declare that the braced-code @var{argument-declaration} is an
+additional @code{yylex} argument declaration.
+@end deffn
+
+For instance:
@example
-if x then if y then win (); else lose;
+%parse-param @{int *nastiness@}
+%lex-param @{int *nastiness@}
+%parse-param @{int *randomness@}
+@end example
-if x then do; if y then win (); else lose; end;
+@noindent
+results in the following signature:
+
+@example
+int yylex (int *nastiness);
+int yyparse (int *nastiness, int *randomness);
@end example
-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 @samp{%define api.pure} is added:
@example
-if x then if y then win (); else lose;
+int yylex (YYSTYPE *lvalp, int *nastiness);
+int yyparse (int *nastiness, int *randomness);
+@end example
-if x then do; if y then win (); end; else lose;
+@noindent
+and finally, if both @samp{%define api.pure} and @code{%locations} are used:
+
+@example
+int yylex (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
+int yyparse (int *nastiness, int *randomness);
@end example
-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 @code{else}'' ambiguity.
+@node Error Reporting
+@section The Error Reporting Function @code{yyerror}
+@cindex error reporting function
+@findex yyerror
+@cindex parse error
+@cindex syntax error
-To avoid warnings from Bison about predictable, legitimate shift/reduce
-conflicts, use the @code{%expect @var{n}} declaration. There will be no
-warning as long as the number of shift/reduce conflicts is exactly @var{n}.
-@xref{Expect Decl, ,Suppressing Conflict Warnings}.
+The Bison parser detects a @dfn{syntax error} (or @dfn{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 @code{YYERROR} (@pxref{Action Features, ,Special Features for Use
+in Actions}).
-The definition of @code{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:
+The Bison parser expects to report the error by calling an error
+reporting function named @code{yyerror}, which you must supply. It is
+called by @code{yyparse} whenever a syntax error is found, and it
+receives one argument. For a syntax error, the string is normally
+@w{@code{"syntax error"}}.
+
+@findex %define parse.error
+If you invoke @samp{%define parse.error verbose} in the Bison
+declarations section (@pxref{Bison Declarations, ,The Bison Declarations
+Section}), then Bison provides a more verbose and specific error message
+string instead of just plain @w{@code{"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, @code{yyparse} calls @code{yyerror} in the usual
+fashion, except that the argument string is @w{@code{"memory exhausted"}}.
+
+In some cases diagnostics like @w{@code{"syntax error"}} are
+translated automatically from English to some other language before
+they are passed to @code{yyerror}. @xref{Internationalization}.
+
+The following definition suffices in simple programs:
@example
@group
-%token IF THEN ELSE variable
-%%
-@end group
-@group
-stmt: expr
- | if_stmt
- ;
+void
+yyerror (char const *s)
+@{
@end group
-
@group
-if_stmt:
- IF expr THEN stmt
- | IF expr THEN stmt ELSE stmt
- ;
+ fprintf (stderr, "%s\n", s);
+@}
@end group
-
-expr: variable
- ;
@end example
-@node Precedence
-@section Operator Precedence
-@cindex operator precedence
-@cindex precedence of operators
-
-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.
+After @code{yyerror} returns to @code{yyparse}, the latter will attempt
+error recovery if you have written suitable error recovery grammar rules
+(@pxref{Error Recovery}). If recovery is impossible, @code{yyparse} will
+immediately return 1.
-@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.
-@end menu
+Obviously, in location tracking pure parsers, @code{yyerror} should have
+an access to the current location.
+This is indeed the case for the @acronym{GLR}
+parsers, but not for the Yacc parser, for historical reasons. I.e., if
+@samp{%locations %define api.pure} is passed then the prototypes for
+@code{yyerror} are:
-@node Why Precedence
-@subsection When Precedence is Needed
+@example
+void yyerror (char const *msg); /* Yacc parsers. */
+void yyerror (YYLTYPE *locp, char const *msg); /* GLR parsers. */
+@end example
-Consider the following ambiguous grammar fragment (ambiguous because the
-input @w{@samp{1 - 2 * 3}} can be parsed in two different ways):
+If @samp{%parse-param @{int *nastiness@}} is used, then:
@example
-@group
-expr: expr '-' expr
- | expr '*' expr
- | expr '<' expr
- | '(' expr ')'
- @dots{}
- ;
-@end group
+void yyerror (int *nastiness, char const *msg); /* Yacc parsers. */
+void yyerror (int *nastiness, char const *msg); /* GLR parsers. */
@end example
-@noindent
-Suppose the parser has seen the tokens @samp{1}, @samp{-} and @samp{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 @samp{)}, we
-must reduce; shifting is invalid because no single rule can reduce the
-token sequence @w{@samp{- 2 )}} or anything starting with that. But if
-the next token is @samp{*} or @samp{<}, 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 @var{op} is shifted, then it must be reduced
-first in order to permit another opportunity to reduce the difference.
-The result is (in effect) @w{@samp{1 - (2 @var{op} 3)}}. On the other
-hand, if the subtraction is reduced before shifting @var{op}, the result
-is @w{@samp{(1 - 2) @var{op} 3}}. Clearly, then, the choice of shift or
-reduce should depend on the relative precedence of the operators
-@samp{-} and @var{op}: @samp{*} should be shifted first, but not
-@samp{<}.
-
-@cindex associativity
-What about input such as @w{@samp{1 - 2 - 5}}; should this be
-@w{@samp{(1 - 2) - 5}} or should it be @w{@samp{1 - (2 - 5)}}? For most
-operators we prefer the former, which is called @dfn{left association}.
-The latter alternative, @dfn{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 @w{@samp{1 - 2}} and the lookahead token is @samp{-}: shifting
-makes right-associativity.
-
-@node Using Precedence
-@subsection Specifying Operator Precedence
-@findex %left
-@findex %right
-@findex %nonassoc
-
-Bison allows you to specify these choices with the operator precedence
-declarations @code{%left} and @code{%right}. Each such declaration
-contains a list of tokens, which are operators whose precedence and
-associativity is being declared. The @code{%left} declaration makes all
-those operators left-associative and the @code{%right} declaration makes
-them right-associative. A third alternative is @code{%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 @code{%left} or
-@code{%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.
-
-@node Precedence Examples
-@subsection Precedence Examples
-
-In our example, we would want the following declarations:
+Finally, @acronym{GLR} and Yacc parsers share the same @code{yyerror} calling
+convention for absolutely pure parsers, i.e., when the calling
+convention of @code{yylex} @emph{and} the calling convention of
+@samp{%define api.pure} are pure.
+I.e.:
@example
-%left '<'
-%left '-'
-%left '*'
+/* Location tracking. */
+%locations
+/* Pure yylex. */
+%define api.pure
+%lex-param @{int *nastiness@}
+/* Pure yyparse. */
+%parse-param @{int *nastiness@}
+%parse-param @{int *randomness@}
@end example
-In a more complete example, which supports other operators as well, we
-would declare them in groups of equal precedence. For example, @code{'+'} is
-declared with @code{'-'}:
+@noindent
+results in the following signatures for all the parser kinds:
@example
-%left '<' '>' '=' NE LE GE
-%left '+' '-'
-%left '*' '/'
+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);
@end example
@noindent
-(Here @code{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.)
+The prototypes are only indications of how the code produced by Bison
+uses @code{yyerror}. Bison-generated code always ignores the returned
+value, so @code{yyerror} can return any type, including @code{void}.
+Also, @code{yyerror} can be a variadic function; that is why the
+message is always passed last.
-@node How Precedence
-@subsection How Precedence Works
+Traditionally @code{yyerror} returns an @code{int} that is always
+ignored, but this is purely for historical reasons, and @code{void} is
+preferable since it more accurately describes the return type for
+@code{yyerror}.
-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. @xref{Contextual
-Precedence, ,Context-Dependent Precedence}.)
+@vindex yynerrs
+The variable @code{yynerrs} contains the number of syntax errors
+reported so far. Normally this variable is global; but if you
+request a pure parser (@pxref{Pure Decl, ,A Pure (Reentrant) Parser})
+then it is a local variable which only the actions can access.
-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 @samp{-v}
-(@pxref{Invocation, ,Invoking Bison}) says how each conflict was
-resolved.
+@node Action Features
+@section Special Features for Use in Actions
+@cindex summary, action features
+@cindex action features summary
-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.
+Here is a table of Bison constructs, variables and macros that
+are useful in actions.
-@node Contextual Precedence
-@section Context-Dependent Precedence
-@cindex context-dependent precedence
-@cindex unary operator precedence
-@cindex precedence, context-dependent
-@cindex precedence, unary operator
-@findex %prec
+@deffn {Variable} $$
+Acts like a variable that contains the semantic value for the
+grouping made by the current rule. @xref{Actions}.
+@end deffn
-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.
+@deffn {Variable} $@var{n}
+Acts like a variable that contains the semantic value for the
+@var{n}th component of the current rule. @xref{Actions}.
+@end deffn
-The Bison precedence declarations, @code{%left}, @code{%right} and
-@code{%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 @code{%prec}
-modifier for rules.
+@deffn {Variable} $<@var{typealt}>$
+Like @code{$$} but specifies alternative @var{typealt} in the union
+specified by the @code{%union} declaration. @xref{Action Types, ,Data
+Types of Values in Actions}.
+@end deffn
-The @code{%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:
+@deffn {Variable} $<@var{typealt}>@var{n}
+Like @code{$@var{n}} but specifies alternative @var{typealt} in the
+union specified by the @code{%union} declaration.
+@xref{Action Types, ,Data Types of Values in Actions}.
+@end deffn
-@example
-%prec @var{terminal-symbol}
-@end example
+@deffn {Macro} YYABORT;
+Return immediately from @code{yyparse}, indicating failure.
+@xref{Parser Function, ,The Parser Function @code{yyparse}}.
+@end deffn
-@noindent
-and it is written after the components of the rule. Its effect is to
-assign the rule the precedence of @var{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 (@pxref{Precedence, ,Operator Precedence}).
+@deffn {Macro} YYACCEPT;
+Return immediately from @code{yyparse}, indicating success.
+@xref{Parser Function, ,The Parser Function @code{yyparse}}.
+@end deffn
-Here is how @code{%prec} solves the problem of unary minus. First, declare
-a precedence for a fictitious terminal symbol named @code{UMINUS}. There
-are no tokens of this type, but the symbol serves to stand for its
-precedence:
+@deffn {Macro} YYBACKUP (@var{token}, @var{value});
+@findex YYBACKUP
+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 @acronym{GLR} parsers.
+It installs a lookahead token with token type @var{token} and
+semantic value @var{value}; then it discards the value that was
+going to be reduced by this rule.
-@example
-@dots{}
-%left '+' '-'
-%left '*'
-%left UMINUS
-@end example
+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 @samp{cannot back up} and performs ordinary error
+recovery.
-Now the precedence of @code{UMINUS} can be used in specific rules:
+In either case, the rest of the action is not executed.
+@end deffn
-@example
-@group
-exp: @dots{}
- | exp '-' exp
- @dots{}
- | '-' exp %prec UMINUS
-@end group
-@end example
+@deffn {Macro} YYEMPTY
+@vindex YYEMPTY
+Value stored in @code{yychar} when there is no lookahead token.
+@end deffn
-@ifset defaultprec
-If you forget to append @code{%prec UMINUS} to the rule for unary
-minus, Bison silently assumes that minus has its usual precedence.
-This kind of problem can be tricky to debug, since one typically
-discovers the mistake only by testing the code.
+@deffn {Macro} YYEOF
+@vindex YYEOF
+Value stored in @code{yychar} when the lookahead is the end of the input
+stream.
+@end deffn
-The @code{%no-default-prec;} declaration makes it easier to discover
-this kind of problem systematically. It causes rules that lack a
-@code{%prec} modifier to have no precedence, even if the last terminal
-symbol mentioned in their components has a declared precedence.
+@deffn {Macro} YYERROR;
+@findex 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 @code{yyerror}, and does not print any message. If you
+want to print an error message, call @code{yyerror} explicitly before
+the @samp{YYERROR;} statement. @xref{Error Recovery}.
+@end deffn
-If @code{%no-default-prec;} is in effect, you must specify @code{%prec}
-for all rules that participate in precedence conflict resolution.
-Then you will see any shift/reduce conflict until you tell Bison how
-to resolve it, either by changing your grammar or by adding an
-explicit precedence. This will probably add declarations to the
-grammar, but it helps to protect against incorrect rule precedences.
+@deffn {Macro} YYRECOVERING
+@findex YYRECOVERING
+The expression @code{YYRECOVERING ()} yields 1 when the parser
+is recovering from a syntax error, and 0 otherwise.
+@xref{Error Recovery}.
+@end deffn
-The effect of @code{%no-default-prec;} can be reversed by giving
-@code{%default-prec;}, which is the default.
-@end ifset
+@deffn {Variable} yychar
+Variable containing either the lookahead token, or @code{YYEOF} when the
+lookahead is the end of the input stream, or @code{YYEMPTY} when no lookahead
+has been performed so the next token is not yet known.
+Do not modify @code{yychar} in a deferred semantic action (@pxref{GLR Semantic
+Actions}).
+@xref{Lookahead, ,Lookahead Tokens}.
+@end deffn
-@node Parser States
-@section Parser States
-@cindex finite-state machine
-@cindex parser state
-@cindex state (of parser)
+@deffn {Macro} yyclearin;
+Discard the current lookahead token. This is useful primarily in
+error rules.
+Do not invoke @code{yyclearin} in a deferred semantic action (@pxref{GLR
+Semantic Actions}).
+@xref{Error Recovery}.
+@end deffn
-The function @code{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.
+@deffn {Macro} yyerrok;
+Resume generating error messages immediately for subsequent syntax
+errors. This is useful primarily in error rules.
+@xref{Error Recovery}.
+@end deffn
-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 @var{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.
+@deffn {Variable} yylloc
+Variable containing the lookahead token location when @code{yychar} is not set
+to @code{YYEMPTY} or @code{YYEOF}.
+Do not modify @code{yylloc} in a deferred semantic action (@pxref{GLR Semantic
+Actions}).
+@xref{Actions and Locations, ,Actions and Locations}.
+@end deffn
-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
-(@pxref{Error Recovery}).
+@deffn {Variable} yylval
+Variable containing the lookahead token semantic value when @code{yychar} is
+not set to @code{YYEMPTY} or @code{YYEOF}.
+Do not modify @code{yylval} in a deferred semantic action (@pxref{GLR Semantic
+Actions}).
+@xref{Actions, ,Actions}.
+@end deffn
-@node Reduce/Reduce
-@section Reduce/Reduce Conflicts
-@cindex reduce/reduce conflict
-@cindex conflicts, reduce/reduce
+@deffn {Value} @@$
+@findex @@$
+Acts like a structure variable containing information on the textual location
+of the grouping made by the current rule. @xref{Locations, ,
+Tracking Locations}.
-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.
+@c Check if those paragraphs are still useful or not.
-For example, here is an erroneous attempt to define a sequence
-of zero or more @code{word} groupings.
+@c @example
+@c struct @{
+@c int first_line, last_line;
+@c int first_column, last_column;
+@c @};
+@c @end example
-@example
-sequence: /* empty */
- @{ printf ("empty sequence\n"); @}
- | maybeword
- | sequence word
- @{ printf ("added word %s\n", $2); @}
- ;
+@c Thus, to get the starting line number of the third component, you would
+@c use @samp{@@3.first_line}.
-maybeword: /* empty */
- @{ printf ("empty maybeword\n"); @}
- | word
- @{ printf ("single word %s\n", $1); @}
- ;
-@end example
+@c In order for the members of this structure to contain valid information,
+@c you must make @code{yylex} supply this information about each token.
+@c If you need only certain members, then @code{yylex} need only fill in
+@c those members.
-@noindent
-The error is an ambiguity: there is more than one way to parse a single
-@code{word} into a @code{sequence}. It could be reduced to a
-@code{maybeword} and then into a @code{sequence} via the second rule.
-Alternatively, nothing-at-all could be reduced into a @code{sequence}
-via the first rule, and this could be combined with the @code{word}
-using the third rule for @code{sequence}.
+@c The use of this feature makes the parser noticeably slower.
+@end deffn
-There is also more than one way to reduce nothing-at-all into a
-@code{sequence}. This can be done directly via the first rule,
-or indirectly via @code{maybeword} and then the second rule.
+@deffn {Value} @@@var{n}
+@findex @@@var{n}
+Acts like a structure variable containing information on the textual location
+of the @var{n}th component of the current rule. @xref{Locations, ,
+Tracking Locations}.
+@end deffn
-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.
+@node Internationalization
+@section Parser Internationalization
+@cindex internationalization
+@cindex i18n
+@cindex NLS
+@cindex gettext
+@cindex bison-po
-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 @code{sequence}:
+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.
+@xref{Users, , The User's View, gettext, GNU @code{gettext} utilities}.
+For example, the shell command @samp{export LC_ALL=fr_CA.UTF-8} might
+set the user's locale to French Canadian using the @acronym{UTF}-8
+encoding. The exact set of available locales depends on the user's
+installation.
-@example
-sequence: /* empty */
- @{ printf ("empty sequence\n"); @}
- | sequence word
- @{ printf ("added word %s\n", $2); @}
- ;
-@end example
+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 @acronym{GNU} Autoconf and
+@acronym{GNU} Automake.
-Here is another common error that yields a reduce/reduce conflict:
+@enumerate
+@item
+@cindex bison-i18n.m4
+Into the directory containing the @acronym{GNU} Autoconf macros used
+by the package---often called @file{m4}---copy the
+@file{bison-i18n.m4} file installed by Bison under
+@samp{share/aclocal/bison-i18n.m4} in Bison's installation directory.
+For example:
@example
-sequence: /* empty */
- | sequence words
- | sequence redirects
- ;
+cp /usr/local/share/aclocal/bison-i18n.m4 m4/bison-i18n.m4
+@end example
-words: /* empty */
- | words word
- ;
+@item
+@findex BISON_I18N
+@vindex BISON_LOCALEDIR
+@vindex YYENABLE_NLS
+In the top-level @file{configure.ac}, after the @code{AM_GNU_GETTEXT}
+invocation, add an invocation of @code{BISON_I18N}. This macro is
+defined in the file @file{bison-i18n.m4} that you copied earlier. It
+causes @samp{configure} to find the value of the
+@code{BISON_LOCALEDIR} variable, and it defines the source-language
+symbol @code{YYENABLE_NLS} to enable translations in the
+Bison-generated parser.
-redirects:/* empty */
- | redirects redirect
- ;
-@end example
+@item
+In the @code{main} function of your program, designate the directory
+containing Bison's runtime message catalog, through a call to
+@samp{bindtextdomain} with domain name @samp{bison-runtime}.
+For example:
-@noindent
-The intention here is to define a sequence which can contain either
-@code{word} or @code{redirect} groupings. The individual definitions of
-@code{sequence}, @code{words} and @code{redirects} are error-free, but the
-three together make a subtle ambiguity: even an empty input can be parsed
-in infinitely many ways!
+@example
+bindtextdomain ("bison-runtime", BISON_LOCALEDIR);
+@end example
-Consider: nothing-at-all could be a @code{words}. Or it could be two
-@code{words} in a row, or three, or any number. It could equally well be a
-@code{redirects}, or two, or any number. Or it could be a @code{words}
-followed by three @code{redirects} and another @code{words}. And so on.
+Typically this appears after any other call @code{bindtextdomain
+(PACKAGE, LOCALEDIR)} that your package already has. Here we rely on
+@samp{BISON_LOCALEDIR} to be defined as a string through the
+@file{Makefile}.
-Here are two ways to correct these rules. First, to make it a single level
-of sequence:
+@item
+In the @file{Makefile.am} that controls the compilation of the @code{main}
+function, make @samp{BISON_LOCALEDIR} available as a C preprocessor macro,
+either in @samp{DEFS} or in @samp{AM_CPPFLAGS}. For example:
@example
-sequence: /* empty */
- | sequence word
- | sequence redirect
- ;
+DEFS = @@DEFS@@ -DBISON_LOCALEDIR='"$(BISON_LOCALEDIR)"'
@end example
-Second, to prevent either a @code{words} or a @code{redirects}
-from being empty:
+or:
@example
-sequence: /* empty */
- | sequence words
- | sequence redirects
- ;
+AM_CPPFLAGS = -DBISON_LOCALEDIR='"$(BISON_LOCALEDIR)"'
+@end example
-words: word
- | words word
- ;
+@item
+Finally, invoke the command @command{autoreconf} to generate the build
+infrastructure.
+@end enumerate
-redirects:redirect
- | redirects redirect
- ;
-@end example
-@node Mystery Conflicts
-@section Mysterious Reduce/Reduce Conflicts
+@node Algorithm
+@chapter The Bison Parser Algorithm
+@cindex Bison parser algorithm
+@cindex algorithm of parser
+@cindex shifting
+@cindex reduction
+@cindex parser stack
+@cindex stack, parser
-Sometimes reduce/reduce conflicts can occur that don't look warranted.
-Here is an example:
+As Bison reads tokens, it pushes them onto a stack along with their
+semantic values. The stack is called the @dfn{parser stack}. Pushing a
+token is traditionally called @dfn{shifting}.
-@example
-@group
-%token ID
+For example, suppose the infix calculator has read @samp{1 + 5 *}, with a
+@samp{3} to come. The stack will have four elements, one for each token
+that was shifted.
-%%
-def: param_spec return_spec ','
- ;
-param_spec:
- type
- | name_list ':' type
- ;
-@end group
-@group
-return_spec:
- type
- | name ':' type
- ;
-@end group
+But the stack does not always have an element for each token read. When
+the last @var{n} tokens and groupings shifted match the components of a
+grammar rule, they can be combined according to that rule. This is called
+@dfn{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:
+
+@example
+1 + 5 * 3
+@end example
+
+@noindent
+and the next input token is a newline character, then the last three
+elements can be reduced to 15 via the rule:
+
+@example
+expr: expr '*' expr;
+@end example
+
+@noindent
+Then the stack contains just these three elements:
+
+@example
+1 + 15
+@end example
+
+@noindent
+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
+(@pxref{Language and Grammar, ,Languages and Context-Free Grammars}).
+
+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.
+@end menu
+
+@node Lookahead
+@section Lookahead Tokens
+@cindex lookahead token
+
+The Bison parser does @emph{not} always reduce immediately as soon as the
+last @var{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
+@dfn{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 (@samp{!}), and allow parentheses for grouping.
+
+@example
@group
-type: ID
+expr: term '+' expr
+ | term
;
@end group
+
@group
-name: ID
- ;
-name_list:
- name
- | name ',' name_list
+term: '(' expr ')'
+ | term '!'
+ | NUMBER
;
@end group
@end example
-It would seem that this grammar can be parsed with only a single token
-of lookahead: when a @code{param_spec} is being read, an @code{ID} is
-a @code{name} if a comma or colon follows, or a @code{type} if another
-@code{ID} follows. In other words, this grammar is @acronym{LR}(1).
+Suppose that the tokens @w{@samp{1 + 2}} have been read and shifted; what
+should be done? If the following token is @samp{)}, then the first three
+tokens must be reduced to form an @code{expr}. This is the only valid
+course, because shifting the @samp{)} would produce a sequence of symbols
+@w{@code{term ')'}}, and no rule allows this.
-@cindex @acronym{LR}(1)
-@cindex @acronym{LALR}(1)
-However, Bison, like most parser generators, cannot actually handle all
-@acronym{LR}(1) grammars. In this grammar, two contexts, that after
-an @code{ID}
-at the beginning of a @code{param_spec} and likewise at the beginning of
-a @code{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 @code{name} and that for reducing to
-a @code{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 @acronym{LALR}(1).
+If the following token is @samp{!}, then it must be shifted immediately so
+that @w{@samp{2 !}} can be reduced to make a @code{term}. If instead the
+parser were to reduce before shifting, @w{@samp{1 + 2}} would become an
+@code{expr}. It would then be impossible to shift the @samp{!} because
+doing so would produce on the stack the sequence of symbols @code{expr
+'!'}. No rule allows that sequence.
-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 @acronym{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.
+@vindex yychar
+@vindex yylval
+@vindex yylloc
+The lookahead token is stored in the variable @code{yychar}.
+Its semantic value and location, if any, are stored in the variables
+@code{yylval} and @code{yylloc}.
+@xref{Action Features, ,Special Features for Use in Actions}.
-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
-@code{return_spec} as follows makes the problem go away:
+@node Shift/Reduce
+@section Shift/Reduce Conflicts
+@cindex conflicts
+@cindex shift/reduce conflicts
+@cindex dangling @code{else}
+@cindex @code{else}, dangling
+
+Suppose we are parsing a language which has if-then and if-then-else
+statements, with a pair of rules like this:
@example
@group
-%token BOGUS
-@dots{}
-%%
-@dots{}
-return_spec:
- type
- | name ':' type
- /* This rule is never used. */
- | ID BOGUS
+if_stmt:
+ IF expr THEN stmt
+ | IF expr THEN stmt ELSE stmt
;
@end group
@end example
-This corrects the problem because it introduces the possibility of an
-additional active rule in the context after the @code{ID} at the beginning of
-@code{return_spec}. This rule is not active in the corresponding context
-in a @code{param_spec}, so the two contexts receive distinct parser states.
-As long as the token @code{BOGUS} is never generated by @code{yylex},
-the added rule cannot alter the way actual input is parsed.
+@noindent
+Here we assume that @code{IF}, @code{THEN} and @code{ELSE} are
+terminal symbols for specific keyword tokens.
-In this particular example, there is another way to solve the problem:
-rewrite the rule for @code{return_spec} to use @code{ID} directly
-instead of via @code{name}. This also causes the two confusing
-contexts to have different sets of active rules, because the one for
-@code{return_spec} activates the altered rule for @code{return_spec}
-rather than the one for @code{name}.
+When the @code{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
+@code{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 @dfn{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 @code{ELSE}, the result is to attach
+the else-clause to the innermost if-statement, making these two inputs
+equivalent:
@example
-param_spec:
- type
- | name_list ':' type
- ;
-return_spec:
- type
- | ID ':' type
- ;
+if x then if y then win (); else lose;
+
+if x then do; if y then win (); else lose; end;
@end example
-For a more detailed exposition of @acronym{LALR}(1) parsers and parser
-generators, please see:
-Frank DeRemer and Thomas Pennello, Efficient Computation of
-@acronym{LALR}(1) Look-Ahead Sets, @cite{@acronym{ACM} Transactions on
-Programming Languages and Systems}, Vol.@: 4, No.@: 4 (October 1982),
-pp.@: 615--649 @uref{http://doi.acm.org/10.1145/69622.357187}.
+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:
-@node Generalized LR Parsing
-@section Generalized @acronym{LR} (@acronym{GLR}) Parsing
-@cindex @acronym{GLR} parsing
-@cindex generalized @acronym{LR} (@acronym{GLR}) parsing
-@cindex ambiguous grammars
-@cindex nondeterministic parsing
+@example
+if x then if y then win (); else lose;
-Bison produces @emph{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 (@pxref{Mystery Conflicts}),
-there are languages where Bison's particular choice of how to
-summarize the input seen so far loses necessary information.
+if x then do; if y then win (); end; else lose;
+@end example
-When you use the @samp{%glr-parser} declaration in your grammar file,
-Bison generates a parser that uses a different algorithm, called
-Generalized @acronym{LR} (or @acronym{GLR}). A Bison @acronym{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 (@pxref{Precedence}) or a
-reduce-reduce conflict. When a @acronym{GLR} parser encounters such a
-situation, it
-effectively @emph{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 @acronym{GLR} parsing stack is what is in effect a tree of states.
+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 @code{else}'' ambiguity.
-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.
+To avoid warnings from Bison about predictable, legitimate shift/reduce
+conflicts, use the @code{%expect @var{n}} declaration. There will be no
+warning as long as the number of shift/reduce conflicts is exactly @var{n}.
+@xref{Expect Decl, ,Suppressing Conflict Warnings}.
-Whenever the parser makes a transition from having multiple
-states to having one, it reverts to the normal @acronym{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 @samp{%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 @samp{%merge} declaration,
-Bison resolves and evaluates both and then calls the merge function on
-the result. Otherwise, it reports an ambiguity.
+The definition of @code{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:
-It is possible to use a data structure for the @acronym{GLR} parsing tree that
-permits the processing of any @acronym{LALR}(1) grammar in linear time (in the
-size of the input), any unambiguous (not necessarily
-@acronym{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 @acronym{LALR}(1) portions of a
-grammar, in particular, it is only slightly slower than with the default
-Bison parser.
+@example
+@group
+%token IF THEN ELSE variable
+%%
+@end group
+@group
+stmt: expr
+ | if_stmt
+ ;
+@end group
-For a more detailed exposition of @acronym{GLR} parsers, please see: Elizabeth
-Scott, Adrian Johnstone and Shamsa Sadaf Hussain, Tomita-Style
-Generalised @acronym{LR} Parsers, Royal Holloway, University of
-London, Department of Computer Science, TR-00-12,
-@uref{http://www.cs.rhul.ac.uk/research/languages/publications/tomita_style_1.ps},
-(2000-12-24).
+@group
+if_stmt:
+ IF expr THEN stmt
+ | IF expr THEN stmt ELSE stmt
+ ;
+@end group
-@node Memory Management
-@section Memory Management, and How to Avoid Memory Exhaustion
-@cindex memory exhaustion
-@cindex memory management
-@cindex stack overflow
-@cindex parser stack overflow
-@cindex overflow of parser stack
+expr: variable
+ ;
+@end example
-The Bison parser stack can run out of memory if too many tokens are shifted and
-not reduced. When this happens, the parser function @code{yyparse}
-calls @code{yyerror} and then returns 2.
+@node Precedence
+@section Operator Precedence
+@cindex operator precedence
+@cindex precedence of operators
-Because Bison parsers have growing stacks, hitting the upper limit
-usually results from using a right recursion instead of a left
-recursion, @xref{Recursion, ,Recursive Rules}.
+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.
-@vindex YYMAXDEPTH
-By defining the macro @code{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.
+@menu
+* Why Precedence:: An example showing why precedence is needed.
+* Using Precedence:: How to specify precedence and associativity.
+* Precedence Only:: How to specify precedence only.
+* Precedence Examples:: How these features are used in the previous example.
+* How Precedence:: How they work.
+@end menu
-The stack space allowed is not necessarily allocated. If you specify a
-large value for @code{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 @code{YYMAXDEPTH} painfully small merely to save
-space for ordinary inputs that do not need much stack.
+@node Why Precedence
+@subsection When Precedence is Needed
-However, do not allow @code{YYMAXDEPTH} to be a value so large that
-arithmetic overflow could occur when calculating the size of the stack
-space. Also, do not allow @code{YYMAXDEPTH} to be less than
-@code{YYINITDEPTH}.
+Consider the following ambiguous grammar fragment (ambiguous because the
+input @w{@samp{1 - 2 * 3}} can be parsed in two different ways):
-@cindex default stack limit
-The default value of @code{YYMAXDEPTH}, if you do not define it, is
-10000.
+@example
+@group
+expr: expr '-' expr
+ | expr '*' expr
+ | expr '<' expr
+ | '(' expr ')'
+ @dots{}
+ ;
+@end group
+@end example
-@vindex YYINITDEPTH
-You can control how much stack is allocated initially by defining the
-macro @code{YYINITDEPTH} to a positive integer. For the C
-@acronym{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.
+@noindent
+Suppose the parser has seen the tokens @samp{1}, @samp{-} and @samp{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 @samp{)}, we
+must reduce; shifting is invalid because no single rule can reduce the
+token sequence @w{@samp{- 2 )}} or anything starting with that. But if
+the next token is @samp{*} or @samp{<}, we have a choice: either
+shifting or reduction would allow the parse to complete, but with
+different results.
-Do not allow @code{YYINITDEPTH} to be greater than @code{YYMAXDEPTH}.
+To decide which one Bison should do, we must consider the results. If
+the next operator token @var{op} is shifted, then it must be reduced
+first in order to permit another opportunity to reduce the difference.
+The result is (in effect) @w{@samp{1 - (2 @var{op} 3)}}. On the other
+hand, if the subtraction is reduced before shifting @var{op}, the result
+is @w{@samp{(1 - 2) @var{op} 3}}. Clearly, then, the choice of shift or
+reduce should depend on the relative precedence of the operators
+@samp{-} and @var{op}: @samp{*} should be shifted first, but not
+@samp{<}.
-@c FIXME: C++ output.
-Because of semantical differences between C and C++, the
-@acronym{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 @code{YYINITDEPTH}. The Bison maintainers hope to fix
-this deficiency in a future release.
+@cindex associativity
+What about input such as @w{@samp{1 - 2 - 5}}; should this be
+@w{@samp{(1 - 2) - 5}} or should it be @w{@samp{1 - (2 - 5)}}? For most
+operators we prefer the former, which is called @dfn{left association}.
+The latter alternative, @dfn{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 @w{@samp{1 - 2}} and the lookahead token is @samp{-}: shifting
+makes right-associativity.
-@node Error Recovery
-@chapter Error Recovery
-@cindex error recovery
-@cindex recovery from errors
+@node Using Precedence
+@subsection Specifying Operator Precedence
+@findex %left
+@findex %nonassoc
+@findex %precedence
+@findex %right
-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.
+Bison allows you to specify these choices with the operator precedence
+declarations @code{%left} and @code{%right}. Each such declaration
+contains a list of tokens, which are operators whose precedence and
+associativity is being declared. The @code{%left} declaration makes all
+those operators left-associative and the @code{%right} declaration makes
+them right-associative. A third alternative is @code{%nonassoc}, which
+declares that it is a syntax error to find the same operator twice ``in a
+row''.
+The last alternative, @code{%precedence}, allows to define only
+precedence and no associativity at all. As a result, any
+associativity-related conflict that remains will be reported as an
+compile-time error. The directive @code{%nonassoc} creates run-time
+error: using the operator in a associative way is a syntax error. The
+directive @code{%precedence} creates compile-time errors: an operator
+@emph{can} be involved in an associativity-related conflict, contrary to
+what expected the grammar author.
-In a simple interactive command parser where each input is one line, it may
-be sufficient to allow @code{yyparse} to return 1 on error and have the
-caller ignore the rest of the input line when that happens (and then call
-@code{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.
+The relative precedence of different operators is controlled by the
+order in which they are declared. The first precedence/associativity
+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.
-@findex error
-You can define how to recover from a syntax error by writing rules to
-recognize the special token @code{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 @code{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.
+@node Precedence Only
+@subsection Specifying Precedence Only
+@findex %precedence
-For example:
+Since @acronym{POSIX} Yacc defines only @code{%left}, @code{%right}, and
+@code{%nonassoc}, which all defines precedence and associativity, little
+attention is paid to the fact that precedence cannot be defined without
+defining associativity. Yet, sometimes, when trying to solve a
+conflict, precedence suffices. In such a case, using @code{%left},
+@code{%right}, or @code{%nonassoc} might hide future (associativity
+related) conflicts that would remain hidden.
+
+The dangling @code{else} ambiguity (@pxref{Shift/Reduce, , Shift/Reduce
+Conflicts}) can be solved explictly. This shift/reduce conflicts occurs
+in the following situation, where the period denotes the current parsing
+state:
@example
-stmnts: /* empty string */
- | stmnts '\n'
- | stmnts exp '\n'
- | stmnts error '\n'
+if @var{e1} then if @var{e2} then @var{s1} . else @var{s2}
@end example
-The fourth rule in this example says that an error followed by a newline
-makes a valid addition to any @code{stmnts}.
+The conflict involves the reduction of the rule @samp{IF expr THEN
+stmt}, which precedence is by default that of its last token
+(@code{THEN}), and the shifting of the token @code{ELSE}. The usual
+disambiguation (attach the @code{else} to the closest @code{if}),
+shifting must be preferred, i.e., the precedence of @code{ELSE} must be
+higher than that of @code{THEN}. But neither is expected to be involved
+in an associativity related conflict, which can be specified as follows.
-What happens if a syntax error occurs in the middle of an @code{exp}? The
-error recovery rule, interpreted strictly, applies to the precise sequence
-of a @code{stmnts}, an @code{error} and a newline. If an error occurs in
-the middle of an @code{exp}, there will probably be some additional tokens
-and subexpressions on the stack after the last @code{stmnts}, and there
-will be tokens to read before the next newline. So the rule is not
-applicable in the ordinary way.
+@example
+%precedence THEN
+%precedence ELSE
+@end example
-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
-@code{error} token is acceptable. (This means that the subexpressions
-already parsed are discarded, back to the last complete @code{stmnts}.)
-At this point the @code{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 @ref{Destructor Decl, , Freeing
-Discarded Symbols}, for a means to reclaim this memory.
+The unary-minus is another typical example where associativity is
+usually over-specified, see @ref{Infix Calc, , Infix Notation
+Calculator: @code{calc}}. The @code{%left} directive is traditionaly
+used to declare the precedence of @code{NEG}, which is more than needed
+since it also defines its associativity. While this is harmless in the
+traditional example, who knows how @code{NEG} might be used in future
+evolutions of the grammar@dots{}
-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:
+@node Precedence Examples
+@subsection Precedence Examples
+
+In our example, we would want the following declarations:
@example
-stmnt: error ';' /* On error, skip until ';' is read. */
+%left '<'
+%left '-'
+%left '*'
@end example
-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:
+In a more complete example, which supports other operators as well, we
+would declare them in groups of equal precedence. For example, @code{'+'} is
+declared with @code{'-'}:
@example
-primary: '(' expr ')'
- | '(' error ')'
- @dots{}
- ;
+%left '<' '>' '=' NE LE GE
+%left '+' '-'
+%left '*' '/'
@end example
-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
-@code{stmnt}. Suppose that instead a spurious semicolon is inserted in the
-middle of a valid @code{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
-@code{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.
+@noindent
+(Here @code{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.)
-Note that rules which accept the @code{error} token may have actions, just
-as any other rules can.
+@node How Precedence
+@subsection How Precedence Works
-@findex yyerrok
-You can make error messages resume immediately by using the macro
-@code{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;
-@samp{yyerrok;} is a valid C statement.
-
-@findex yyclearin
-The previous lookahead token is reanalyzed immediately after an error. If
-this is unacceptable, then the macro @code{yyclearin} may be used to clear
-this token. Write the statement @samp{yyclearin;} in the error rule's
-action.
-@xref{Action Features, ,Special Features for Use in Actions}.
-
-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 @samp{yyclearin;}.
-
-@vindex YYRECOVERING
-The expression @code{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.
+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. @xref{Contextual
+Precedence, ,Context-Dependent Precedence}.)
-@node Context Dependency
-@chapter Handling Context Dependencies
+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 @samp{-v}
+(@pxref{Invocation, ,Invoking Bison}) says how each conflict was
+resolved.
-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 @dfn{kludges}) may enable you to write Bison parsers for such
-languages.
+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.
-@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.
-@end menu
+@node Contextual Precedence
+@section Context-Dependent Precedence
+@cindex context-dependent precedence
+@cindex unary operator precedence
+@cindex precedence, context-dependent
+@cindex precedence, unary operator
+@findex %prec
-(Actually, ``kludge'' means any technique that gets its job done but is
-neither clean nor robust.)
+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.
-@node Semantic Tokens
-@section Semantic Info in Token Types
+The Bison precedence declarations
+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 @code{%prec}
+modifier for rules.
-The C language has a context dependency: the way an identifier is used
-depends on what its current meaning is. For example, consider this:
+The @code{%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:
@example
-foo (x);
+%prec @var{terminal-symbol}
@end example
-This looks like a function call statement, but if @code{foo} is a typedef
-name, then this is actually a declaration of @code{x}. How can a Bison
-parser for C decide how to parse this input?
+@noindent
+and it is written after the components of the rule. Its effect is to
+assign the rule the precedence of @var{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 (@pxref{Precedence, ,Operator Precedence}).
-The method used in @acronym{GNU} C is to have two different token types,
-@code{IDENTIFIER} and @code{TYPENAME}. When @code{yylex} finds an
-identifier, it looks up the current declaration of the identifier in order
-to decide which token type to return: @code{TYPENAME} if the identifier is
-declared as a typedef, @code{IDENTIFIER} otherwise.
+Here is how @code{%prec} solves the problem of unary minus. First, declare
+a precedence for a fictitious terminal symbol named @code{UMINUS}. There
+are no tokens of this type, but the symbol serves to stand for its
+precedence:
-The grammar rules can then express the context dependency by the choice of
-token type to recognize. @code{IDENTIFIER} is accepted as an expression,
-but @code{TYPENAME} is not. @code{TYPENAME} can start a declaration, but
-@code{IDENTIFIER} cannot. In contexts where the meaning of the identifier
-is @emph{not} significant, such as in declarations that can shadow a
-typedef name, either @code{TYPENAME} or @code{IDENTIFIER} is
-accepted---there is one rule for each of the two token types.
+@example
+@dots{}
+%left '+' '-'
+%left '*'
+%left UMINUS
+@end example
-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:
+Now the precedence of @code{UMINUS} can be used in specific rules:
@example
-typedef int foo, bar;
-int baz (void)
-@{
- static bar (bar); /* @r{redeclare @code{bar} as static variable} */
- extern foo foo (foo); /* @r{redeclare @code{foo} as function} */
- return foo (bar);
-@}
+@group
+exp: @dots{}
+ | exp '-' exp
+ @dots{}
+ | '-' exp %prec UMINUS
+@end group
@end example
-Unfortunately, the name being declared is separated from the declaration
-construct itself by a complicated syntactic structure---the ``declarator''.
+@ifset defaultprec
+If you forget to append @code{%prec UMINUS} to the rule for unary
+minus, Bison silently assumes that minus has its usual precedence.
+This kind of problem can be tricky to debug, since one typically
+discovers the mistake only by testing the code.
-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:
+The @code{%no-default-prec;} declaration makes it easier to discover
+this kind of problem systematically. It causes rules that lack a
+@code{%prec} modifier to have no precedence, even if the last terminal
+symbol mentioned in their components has a declared precedence.
-@example
-initdcl:
- declarator maybeasm '='
- init
- | declarator maybeasm
- ;
+If @code{%no-default-prec;} is in effect, you must specify @code{%prec}
+for all rules that participate in precedence conflict resolution.
+Then you will see any shift/reduce conflict until you tell Bison how
+to resolve it, either by changing your grammar or by adding an
+explicit precedence. This will probably add declarations to the
+grammar, but it helps to protect against incorrect rule precedences.
-notype_initdcl:
- notype_declarator maybeasm '='
- init
- | notype_declarator maybeasm
- ;
-@end example
+The effect of @code{%no-default-prec;} can be reversed by giving
+@code{%default-prec;}, which is the default.
+@end ifset
-@noindent
-Here @code{initdcl} can redeclare a typedef name, but @code{notype_initdcl}
-cannot. The distinction between @code{declarator} and
-@code{notype_declarator} is the same sort of thing.
+@node Parser States
+@section Parser States
+@cindex finite-state machine
+@cindex parser state
+@cindex state (of parser)
-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.
+The function @code{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.
-@node Lexical Tie-ins
-@section Lexical Tie-ins
-@cindex lexical tie-in
+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 @var{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.
-One way to handle context-dependency is the @dfn{lexical tie-in}: a flag
-which is set by Bison actions, whose purpose is to alter the way tokens are
-parsed.
+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
+(@pxref{Error Recovery}).
-For example, suppose we have a language vaguely like C, but with a special
-construct @samp{hex (@var{hex-expr})}. After the keyword @code{hex} comes
-an expression in parentheses in which all integers are hexadecimal. In
-particular, the token @samp{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:
+@node Reduce/Reduce
+@section Reduce/Reduce Conflicts
+@cindex reduce/reduce conflict
+@cindex conflicts, reduce/reduce
+
+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 @code{word} groupings.
@example
-@group
-%@{
- int hexflag;
- int yylex (void);
- void yyerror (char const *);
-%@}
-%%
-@dots{}
-@end group
-@group
-expr: IDENTIFIER
- | constant
- | HEX '('
- @{ hexflag = 1; @}
- expr ')'
- @{ hexflag = 0;
- $$ = $4; @}
- | expr '+' expr
- @{ $$ = make_sum ($1, $3); @}
- @dots{}
+sequence: /* empty */
+ @{ printf ("empty sequence\n"); @}
+ | maybeword
+ | sequence word
+ @{ printf ("added word %s\n", $2); @}
;
-@end group
-@group
-constant:
- INTEGER
- | STRING
+maybeword: /* empty */
+ @{ printf ("empty maybeword\n"); @}
+ | word
+ @{ printf ("single word %s\n", $1); @}
;
-@end group
@end example
@noindent
-Here we assume that @code{yylex} looks at the value of @code{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 @code{hexflag} shown in the prologue of the parser file
-is needed to make it accessible to the actions (@pxref{Prologue, ,The Prologue}).
-You must also write the code in @code{yylex} to obey the flag.
+The error is an ambiguity: there is more than one way to parse a single
+@code{word} into a @code{sequence}. It could be reduced to a
+@code{maybeword} and then into a @code{sequence} via the second rule.
+Alternatively, nothing-at-all could be reduced into a @code{sequence}
+via the first rule, and this could be combined with the @code{word}
+using the third rule for @code{sequence}.
-@node Tie-in Recovery
-@section Lexical Tie-ins and Error Recovery
+There is also more than one way to reduce nothing-at-all into a
+@code{sequence}. This can be done directly via the first rule,
+or indirectly via @code{maybeword} and then the second rule.
-Lexical tie-ins make strict demands on any error recovery rules you have.
-@xref{Error Recovery}.
+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.
-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:
+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 @code{sequence}:
@example
-stmt: expr ';'
- | IF '(' expr ')' stmt @{ @dots{} @}
- @dots{}
- error ';'
- @{ hexflag = 0; @}
+sequence: /* empty */
+ @{ printf ("empty sequence\n"); @}
+ | sequence word
+ @{ printf ("added word %s\n", $2); @}
;
@end example
-If there is a syntax error in the middle of a @samp{hex (@var{expr})}
-construct, this error rule will apply, and then the action for the
-completed @samp{hex (@var{expr})} will never run. So @code{hexflag} would
-remain set for the entire rest of the input, or until the next @code{hex}
-keyword, causing identifiers to be misinterpreted as integers.
+Here is another common error that yields a reduce/reduce conflict:
-To avoid this problem the error recovery rule itself clears @code{hexflag}.
+@example
+sequence: /* empty */
+ | sequence words
+ | sequence redirects
+ ;
-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:
+words: /* empty */
+ | words word
+ ;
-@example
-@group
-expr: @dots{}
- | '(' expr ')'
- @{ $$ = $2; @}
- | '(' error ')'
- @dots{}
-@end group
+redirects:/* empty */
+ | redirects redirect
+ ;
@end example
-If this rule acts within the @code{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 @code{hex} construct should be parsed with the flag still in effect.
+@noindent
+The intention here is to define a sequence which can contain either
+@code{word} or @code{redirect} groupings. The individual definitions of
+@code{sequence}, @code{words} and @code{redirects} are error-free, but the
+three together make a subtle ambiguity: even an empty input can be parsed
+in infinitely many ways!
-What if there is an error recovery rule which might abort out of the
-@code{hex} construct or might not, depending on circumstances? There is no
-way you can write the action to determine whether a @code{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.
+Consider: nothing-at-all could be a @code{words}. Or it could be two
+@code{words} in a row, or three, or any number. It could equally well be a
+@code{redirects}, or two, or any number. Or it could be a @code{words}
+followed by three @code{redirects} and another @code{words}. And so on.
-@c ================================================== Debugging Your Parser
+Here are two ways to correct these rules. First, to make it a single level
+of sequence:
-@node Debugging
-@chapter Debugging Your Parser
+@example
+sequence: /* empty */
+ | sequence word
+ | sequence redirect
+ ;
+@end example
-Developing a parser can be a challenge, especially if you don't
-understand the algorithm (@pxref{Algorithm, ,The Bison Parser
-Algorithm}). Even so, sometimes a detailed description of the automaton
-can help (@pxref{Understanding, , Understanding Your Parser}), or
-tracing the execution of the parser can give some insight on why it
-behaves improperly (@pxref{Tracing, , Tracing Your Parser}).
+Second, to prevent either a @code{words} or a @code{redirects}
+from being empty:
-@menu
-* Understanding:: Understanding the structure of your parser.
-* Tracing:: Tracing the execution of your parser.
-@end menu
+@example
+sequence: /* empty */
+ | sequence words
+ | sequence redirects
+ ;
-@node Understanding
-@section Understanding Your Parser
+words: word
+ | words word
+ ;
-As documented elsewhere (@pxref{Algorithm, ,The Bison Parser Algorithm})
-Bison parsers are @dfn{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).
+redirects:redirect
+ | redirects redirect
+ ;
+@end example
-The textual file is generated when the options @option{--report} or
-@option{--verbose} are specified, see @xref{Invocation, , Invoking
-Bison}. Its name is made by removing @samp{.tab.c} or @samp{.c} from
-the parser output file name, and adding @samp{.output} instead.
-Therefore, if the input file is @file{foo.y}, then the parser file is
-called @file{foo.tab.c} by default. As a consequence, the verbose
-output file is called @file{foo.output}.
+@node Mystery Conflicts
+@section Mysterious Reduce/Reduce Conflicts
-The following grammar file, @file{calc.y}, will be used in the sequel:
+Sometimes reduce/reduce conflicts can occur that don't look warranted.
+Here is an example:
@example
-%token NUM STR
-%left '+' '-'
-%left '*'
-%%
-exp: exp '+' exp
- | exp '-' exp
- | exp '*' exp
- | exp '/' exp
- | NUM
- ;
-useless: STR;
+@group
+%token ID
+
%%
+def: param_spec return_spec ','
+ ;
+param_spec:
+ type
+ | name_list ':' type
+ ;
+@end group
+@group
+return_spec:
+ type
+ | name ':' type
+ ;
+@end group
+@group
+type: ID
+ ;
+@end group
+@group
+name: ID
+ ;
+name_list:
+ name
+ | name ',' name_list
+ ;
+@end group
@end example
-@command{bison} reports:
-
-@example
-calc.y: warning: 1 useless nonterminal and 1 useless rule
-calc.y:11.1-7: warning: useless nonterminal: useless
-calc.y:11.10-12: warning: useless rule: useless: STR
-calc.y: conflicts: 7 shift/reduce
-@end example
+It would seem that this grammar can be parsed with only a single token
+of lookahead: when a @code{param_spec} is being read, an @code{ID} is
+a @code{name} if a comma or colon follows, or a @code{type} if another
+@code{ID} follows. In other words, this grammar is @acronym{LR}(1).
-When given @option{--report=state}, in addition to @file{calc.tab.c}, it
-creates a file @file{calc.output} with contents detailed below. The
-order of the output and the exact presentation might vary, but the
-interpretation is the same.
+@cindex @acronym{LR}(1)
+@cindex @acronym{LALR}(1)
+However, for historical reasons, Bison cannot by default handle all
+@acronym{LR}(1) grammars.
+In this grammar, two contexts, that after an @code{ID} at the beginning
+of a @code{param_spec} and likewise at the beginning of a
+@code{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 @code{name} and that for reducing to
+a @code{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 @acronym{LALR}(1).
-The first section includes details on conflicts that were solved thanks
-to precedence and/or associativity:
+For many practical grammars (specifically those that fall into the
+non-@acronym{LR}(1) class), the limitations of @acronym{LALR}(1) result in
+difficulties beyond just mysterious reduce/reduce conflicts.
+The best way to fix all these problems is to select a different parser
+table generation algorithm.
+Either @acronym{IELR}(1) or canonical @acronym{LR}(1) would suffice, but
+the former is more efficient and easier to debug during development.
+@xref{Decl Summary,,lr.type}, for details.
+(Bison's @acronym{IELR}(1) and canonical @acronym{LR}(1) implementations
+are experimental.
+More user feedback will help to stabilize them.)
+
+If you instead wish to work around @acronym{LALR}(1)'s limitations, you
+can often fix a mysterious conflict 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
+@code{return_spec} as follows makes the problem go away:
@example
-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.
-@exdent @dots{}
+@group
+%token BOGUS
+@dots{}
+%%
+@dots{}
+return_spec:
+ type
+ | name ':' type
+ /* This rule is never used. */
+ | ID BOGUS
+ ;
+@end group
@end example
-@noindent
-The next section lists states that still have conflicts.
+This corrects the problem because it introduces the possibility of an
+additional active rule in the context after the @code{ID} at the beginning of
+@code{return_spec}. This rule is not active in the corresponding context
+in a @code{param_spec}, so the two contexts receive distinct parser states.
+As long as the token @code{BOGUS} is never generated by @code{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 @code{return_spec} to use @code{ID} directly
+instead of via @code{name}. This also causes the two confusing
+contexts to have different sets of active rules, because the one for
+@code{return_spec} activates the altered rule for @code{return_spec}
+rather than the one for @code{name}.
@example
-State 8 conflicts: 1 shift/reduce
-State 9 conflicts: 1 shift/reduce
-State 10 conflicts: 1 shift/reduce
-State 11 conflicts: 4 shift/reduce
+param_spec:
+ type
+ | name_list ':' type
+ ;
+return_spec:
+ type
+ | ID ':' type
+ ;
@end example
-@noindent
-@cindex token, useless
-@cindex useless token
-@cindex nonterminal, useless
-@cindex useless nonterminal
-@cindex rule, useless
-@cindex useless rule
-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 ``not used''
-below):
-
-@example
-Useless nonterminals:
- useless
+For a more detailed exposition of @acronym{LALR}(1) parsers and parser
+generators, please see:
+Frank DeRemer and Thomas Pennello, Efficient Computation of
+@acronym{LALR}(1) Look-Ahead Sets, @cite{@acronym{ACM} Transactions on
+Programming Languages and Systems}, Vol.@: 4, No.@: 4 (October 1982),
+pp.@: 615--649 @uref{http://doi.acm.org/10.1145/69622.357187}.
-Terminals which are not used:
- STR
+@node Generalized LR Parsing
+@section Generalized @acronym{LR} (@acronym{GLR}) Parsing
+@cindex @acronym{GLR} parsing
+@cindex generalized @acronym{LR} (@acronym{GLR}) parsing
+@cindex ambiguous grammars
+@cindex nondeterministic parsing
-Useless rules:
-#6 useless: STR;
-@end example
+Bison produces @emph{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 (@pxref{Mystery Conflicts}),
+there are languages where Bison's default choice of how to
+summarize the input seen so far loses necessary information.
-@noindent
-The next section reproduces the exact grammar that Bison used:
+When you use the @samp{%glr-parser} declaration in your grammar file,
+Bison generates a parser that uses a different algorithm, called
+Generalized @acronym{LR} (or @acronym{GLR}). A Bison @acronym{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 (@pxref{Precedence}) or a
+reduce-reduce conflict. When a @acronym{GLR} parser encounters such a
+situation, it
+effectively @emph{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 @acronym{GLR} parsing stack is what is in effect a tree of states.
-@example
-Grammar
+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.
- 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
-@end example
+Whenever the parser makes a transition from having multiple
+states to having one, it reverts to the normal deterministic 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 @samp{%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 @samp{%merge} declaration,
+Bison resolves and evaluates both and then calls the merge function on
+the result. Otherwise, it reports an ambiguity.
-@noindent
-and reports the uses of the symbols:
+It is possible to use a data structure for the @acronym{GLR} parsing tree that
+permits the processing of any @acronym{LR}(1) grammar in linear time (in the
+size of the input), any unambiguous (not necessarily
+@acronym{LR}(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 @acronym{LR}(1) portions of a
+grammar, in particular, it is only slightly slower than with the
+deterministic @acronym{LR}(1) Bison parser.
-@example
-Terminals, with rules where they appear
+For a more detailed exposition of @acronym{GLR} parsers, please see: Elizabeth
+Scott, Adrian Johnstone and Shamsa Sadaf Hussain, Tomita-Style
+Generalised @acronym{LR} Parsers, Royal Holloway, University of
+London, Department of Computer Science, TR-00-12,
+@uref{http://www.cs.rhul.ac.uk/research/languages/publications/tomita_style_1.ps},
+(2000-12-24).
-$end (0) 0
-'*' (42) 3
-'+' (43) 1
-'-' (45) 2
-'/' (47) 4
-error (256)
-NUM (258) 5
+@node Memory Management
+@section Memory Management, and How to Avoid Memory Exhaustion
+@cindex memory exhaustion
+@cindex memory management
+@cindex stack overflow
+@cindex parser stack overflow
+@cindex overflow of parser stack
-Nonterminals, with rules where they appear
+The Bison parser stack can run out of memory if too many tokens are shifted and
+not reduced. When this happens, the parser function @code{yyparse}
+calls @code{yyerror} and then returns 2.
-$accept (8)
- on left: 0
-exp (9)
- on left: 1 2 3 4 5, on right: 0 1 2 3 4
-@end example
+Because Bison parsers have growing stacks, hitting the upper limit
+usually results from using a right recursion instead of a left
+recursion, @xref{Recursion, ,Recursive Rules}.
-@noindent
-@cindex item
-@cindex pointed rule
-@cindex rule, pointed
-Bison then proceeds onto the automaton itself, describing each state
-with it set of @dfn{items}, also known as @dfn{pointed rules}. Each
-item is a production rule together with a point (marked by @samp{.})
-that the input cursor.
+@vindex YYMAXDEPTH
+By defining the macro @code{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.
-@example
-state 0
+The stack space allowed is not necessarily allocated. If you specify a
+large value for @code{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 @code{YYMAXDEPTH} painfully small merely to save
+space for ordinary inputs that do not need much stack.
- $accept -> . exp $ (rule 0)
+However, do not allow @code{YYMAXDEPTH} to be a value so large that
+arithmetic overflow could occur when calculating the size of the stack
+space. Also, do not allow @code{YYMAXDEPTH} to be less than
+@code{YYINITDEPTH}.
- NUM shift, and go to state 1
+@cindex default stack limit
+The default value of @code{YYMAXDEPTH}, if you do not define it, is
+10000.
- exp go to state 2
-@end example
+@vindex YYINITDEPTH
+You can control how much stack is allocated initially by defining the
+macro @code{YYINITDEPTH} to a positive integer. For the deterministic
+parser in C, this value must be a compile-time constant
+unless you are assuming C99 or some other target language or compiler
+that allows variable-length arrays. The default is 200.
-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, @code{exp}). When the parser returns to this state right
-after having reduced a rule that produced an @code{exp}, the control
-flow jumps to state 2. If there is no such transition on a nonterminal
-symbol, and the lookahead is a @code{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.''
+Do not allow @code{YYINITDEPTH} to be greater than @code{YYMAXDEPTH}.
-@cindex core, item set
-@cindex item set core
-@cindex kernel, item set
-@cindex item set core
-Even though the only active rule in state 0 seems to be rule 0, the
-report lists @code{NUM} as a lookahead token because @code{NUM} can be
-at the beginning of any rule deriving an @code{exp}. By default Bison
-reports the so-called @dfn{core} or @dfn{kernel} of the item set, but if
-you want to see more detail you can invoke @command{bison} with
-@option{--report=itemset} to list all the items, include those that can
-be derived:
+@c FIXME: C++ output.
+Because of semantical differences between C and C++, the deterministic
+parsers in C produced by Bison cannot grow when compiled
+by C++ compilers. In this precise case (compiling a C parser as C++) you are
+suggested to grow @code{YYINITDEPTH}. The Bison maintainers hope to fix
+this deficiency in a future release.
-@example
-state 0
+@node Error Recovery
+@chapter Error Recovery
+@cindex error recovery
+@cindex recovery from errors
- $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)
+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.
- NUM shift, and go to state 1
+In a simple interactive command parser where each input is one line, it may
+be sufficient to allow @code{yyparse} to return 1 on error and have the
+caller ignore the rest of the input line when that happens (and then call
+@code{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.
- exp go to state 2
-@end example
+@findex error
+You can define how to recover from a syntax error by writing rules to
+recognize the special token @code{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 @code{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.
-@noindent
-In the state 1...
+For example:
@example
-state 1
-
- exp -> NUM . (rule 5)
-
- $default reduce using rule 5 (exp)
+stmnts: /* empty string */
+ | stmnts '\n'
+ | stmnts exp '\n'
+ | stmnts error '\n'
@end example
-@noindent
-the rule 5, @samp{exp: NUM;}, is completed. Whatever the lookahead token
-(@samp{$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 (@samp{exp: go to state 2}).
-
-@example
-state 2
+The fourth rule in this example says that an error followed by a newline
+makes a valid addition to any @code{stmnts}.
- $accept -> exp . $ (rule 0)
- exp -> exp . '+' exp (rule 1)
- exp -> exp . '-' exp (rule 2)
- exp -> exp . '*' exp (rule 3)
- exp -> exp . '/' exp (rule 4)
+What happens if a syntax error occurs in the middle of an @code{exp}? The
+error recovery rule, interpreted strictly, applies to the precise sequence
+of a @code{stmnts}, an @code{error} and a newline. If an error occurs in
+the middle of an @code{exp}, there will probably be some additional tokens
+and subexpressions on the stack after the last @code{stmnts}, and there
+will be tokens to read before the next newline. So the rule is not
+applicable in the ordinary way.
- $ 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
-@end example
-
-@noindent
-In state 2, the automaton can only shift a symbol. For instance,
-because of the item @samp{exp -> exp . '+' exp}, if the lookahead if
-@samp{+}, it will be shifted on the parse stack, and the automaton
-control will jump to state 4, corresponding to the item @samp{exp -> exp
-'+' . exp}. Since there is no default action, any other token than
-those listed above will trigger a syntax error.
+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
+@code{error} token is acceptable. (This means that the subexpressions
+already parsed are discarded, back to the last complete @code{stmnts}.)
+At this point the @code{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 @ref{Destructor Decl, , Freeing
+Discarded Symbols}, for a means to reclaim this memory.
-The state 3 is named the @dfn{final state}, or the @dfn{accepting
-state}:
+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:
@example
-state 3
-
- $accept -> exp $ . (rule 0)
-
- $default accept
+stmnt: error ';' /* On error, skip until ';' is read. */
@end example
-@noindent
-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.
+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:
@example
-state 4
-
- exp -> exp '+' . exp (rule 1)
+primary: '(' expr ')'
+ | '(' error ')'
+ @dots{}
+ ;
+@end example
- NUM shift, and go to state 1
+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
+@code{stmnt}. Suppose that instead a spurious semicolon is inserted in the
+middle of a valid @code{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
+@code{stmnt}.
- exp go to state 8
+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.
-state 5
+Note that rules which accept the @code{error} token may have actions, just
+as any other rules can.
- exp -> exp '-' . exp (rule 2)
+@findex yyerrok
+You can make error messages resume immediately by using the macro
+@code{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;
+@samp{yyerrok;} is a valid C statement.
- NUM shift, and go to state 1
+@findex yyclearin
+The previous lookahead token is reanalyzed immediately after an error. If
+this is unacceptable, then the macro @code{yyclearin} may be used to clear
+this token. Write the statement @samp{yyclearin;} in the error rule's
+action.
+@xref{Action Features, ,Special Features for Use in Actions}.
- exp go to state 9
+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 @samp{yyclearin;}.
-state 6
+@vindex YYRECOVERING
+The expression @code{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.
- exp -> exp '*' . exp (rule 3)
+@node Context Dependency
+@chapter Handling Context Dependencies
- NUM shift, and go to state 1
+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 @dfn{kludges}) may enable you to write Bison parsers for such
+languages.
- exp go to state 10
+@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.
+@end menu
-state 7
+(Actually, ``kludge'' means any technique that gets its job done but is
+neither clean nor robust.)
- exp -> exp '/' . exp (rule 4)
+@node Semantic Tokens
+@section Semantic Info in Token Types
- NUM shift, and go to state 1
+The C language has a context dependency: the way an identifier is used
+depends on what its current meaning is. For example, consider this:
- exp go to state 11
+@example
+foo (x);
@end example
-As was announced in beginning of the report, @samp{State 8 conflicts:
-1 shift/reduce}:
+This looks like a function call statement, but if @code{foo} is a typedef
+name, then this is actually a declaration of @code{x}. How can a Bison
+parser for C decide how to parse this input?
-@example
-state 8
+The method used in @acronym{GNU} C is to have two different token types,
+@code{IDENTIFIER} and @code{TYPENAME}. When @code{yylex} finds an
+identifier, it looks up the current declaration of the identifier in order
+to decide which token type to return: @code{TYPENAME} if the identifier is
+declared as a typedef, @code{IDENTIFIER} otherwise.
- 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)
+The grammar rules can then express the context dependency by the choice of
+token type to recognize. @code{IDENTIFIER} is accepted as an expression,
+but @code{TYPENAME} is not. @code{TYPENAME} can start a declaration, but
+@code{IDENTIFIER} cannot. In contexts where the meaning of the identifier
+is @emph{not} significant, such as in declarations that can shadow a
+typedef name, either @code{TYPENAME} or @code{IDENTIFIER} is
+accepted---there is one rule for each of the two token types.
- '*' shift, and go to state 6
- '/' shift, and go to state 7
+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:
- '/' [reduce using rule 1 (exp)]
- $default reduce using rule 1 (exp)
+@example
+typedef int foo, bar;
+int baz (void)
+@{
+ static bar (bar); /* @r{redeclare @code{bar} as static variable} */
+ extern foo foo (foo); /* @r{redeclare @code{foo} as function} */
+ return foo (bar);
+@}
@end example
-Indeed, there are two actions associated to the lookahead @samp{/}:
-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 @samp{/}, the
-sentence @samp{NUM + NUM / NUM} can be parsed as @samp{NUM + (NUM /
-NUM)}, which corresponds to shifting @samp{/}, or as @samp{(NUM + NUM) /
-NUM}, which corresponds to reducing rule 1.
-
-Because in @acronym{LALR}(1) parsing a single decision can be made, Bison
-arbitrarily chose to disable the reduction, see @ref{Shift/Reduce, ,
-Shift/Reduce Conflicts}. Discarded actions are reported in between
-square brackets.
+Unfortunately, the name being declared is separated from the declaration
+construct itself by a complicated syntactic structure---the ``declarator''.
-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
-@emph{and} reducing is possible or when @emph{several} reductions are
-possible, the lookahead is required to select the action. State 8 is
-one such state: if the lookahead is @samp{*} or @samp{/} 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 @samp{*}, since we specified that @samp{*} has higher
-precedence than @samp{+}. More generally, some items are eligible only
-with some set of possible lookahead tokens. When run with
-@option{--report=lookahead}, Bison specifies these lookahead tokens:
+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:
@example
-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
+initdcl:
+ declarator maybeasm '='
+ init
+ | declarator maybeasm
+ ;
- '/' [reduce using rule 1 (exp)]
- $default reduce using rule 1 (exp)
+notype_initdcl:
+ notype_declarator maybeasm '='
+ init
+ | notype_declarator maybeasm
+ ;
@end example
-The remaining states are similar:
-
-@example
-state 9
+@noindent
+Here @code{initdcl} can redeclare a typedef name, but @code{notype_initdcl}
+cannot. The distinction between @code{declarator} and
+@code{notype_declarator} is the same sort of thing.
- 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)
+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.
- '*' shift, and go to state 6
- '/' shift, and go to state 7
+@node Lexical Tie-ins
+@section Lexical Tie-ins
+@cindex lexical tie-in
- '/' [reduce using rule 2 (exp)]
- $default reduce using rule 2 (exp)
+One way to handle context-dependency is the @dfn{lexical tie-in}: a flag
+which is set by Bison actions, whose purpose is to alter the way tokens are
+parsed.
-state 10
+For example, suppose we have a language vaguely like C, but with a special
+construct @samp{hex (@var{hex-expr})}. After the keyword @code{hex} comes
+an expression in parentheses in which all integers are hexadecimal. In
+particular, the token @samp{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:
- 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
+@example
+@group
+%@{
+ int hexflag;
+ int yylex (void);
+ void yyerror (char const *);
+%@}
+%%
+@dots{}
+@end group
+@group
+expr: IDENTIFIER
+ | constant
+ | HEX '('
+ @{ hexflag = 1; @}
+ expr ')'
+ @{ hexflag = 0;
+ $$ = $4; @}
+ | expr '+' expr
+ @{ $$ = make_sum ($1, $3); @}
+ @dots{}
+ ;
+@end group
- '+' [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)
+@group
+constant:
+ INTEGER
+ | STRING
+ ;
+@end group
@end example
@noindent
-Observe that state 11 contains conflicts not only due to the lack of
-precedence of @samp{/} with respect to @samp{+}, @samp{-}, and
-@samp{*}, but also because the
-associativity of @samp{/} is not specified.
+Here we assume that @code{yylex} looks at the value of @code{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 @code{hexflag} shown in the prologue of the parser file
+is needed to make it accessible to the actions (@pxref{Prologue, ,The Prologue}).
+You must also write the code in @code{yylex} to obey the flag.
-@node Tracing
-@section Tracing Your Parser
-@findex yydebug
-@cindex debugging
-@cindex tracing the parser
+@node Tie-in Recovery
+@section Lexical Tie-ins and Error Recovery
-If a Bison grammar compiles properly but doesn't do what you want when it
-runs, the @code{yydebug} parser-trace feature can help you figure out why.
+Lexical tie-ins make strict demands on any error recovery rules you have.
+@xref{Error Recovery}.
-There are several means to enable compilation of trace facilities:
+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:
-@table @asis
-@item the macro @code{YYDEBUG}
-@findex YYDEBUG
-Define the macro @code{YYDEBUG} to a nonzero value when you compile the
-parser. This is compliant with @acronym{POSIX} Yacc. You could use
-@samp{-DYYDEBUG=1} as a compiler option or you could put @samp{#define
-YYDEBUG 1} in the prologue of the grammar file (@pxref{Prologue, , The
-Prologue}).
+@example
+stmt: expr ';'
+ | IF '(' expr ')' stmt @{ @dots{} @}
+ @dots{}
+ error ';'
+ @{ hexflag = 0; @}
+ ;
+@end example
-@item the option @option{-t}, @option{--debug}
-Use the @samp{-t} option when you run Bison (@pxref{Invocation,
-,Invoking Bison}). This is @acronym{POSIX} compliant too.
+If there is a syntax error in the middle of a @samp{hex (@var{expr})}
+construct, this error rule will apply, and then the action for the
+completed @samp{hex (@var{expr})} will never run. So @code{hexflag} would
+remain set for the entire rest of the input, or until the next @code{hex}
+keyword, causing identifiers to be misinterpreted as integers.
-@item the directive @samp{%debug}
-@findex %debug
-Add the @code{%debug} directive (@pxref{Decl Summary, ,Bison
-Declaration Summary}). This is a Bison extension, which will prove
-useful when Bison will output parsers for languages that don't use a
-preprocessor. Unless @acronym{POSIX} and Yacc portability matter to
-you, this is
-the preferred solution.
-@end table
+To avoid this problem the error recovery rule itself clears @code{hexflag}.
-We suggest that you always enable the debug option so that debugging is
-always possible.
+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:
-The trace facility outputs messages with macro calls of the form
-@code{YYFPRINTF (stderr, @var{format}, @var{args})} where
-@var{format} and @var{args} are the usual @code{printf} format and
-arguments. If you define @code{YYDEBUG} to a nonzero value but do not
-define @code{YYFPRINTF}, @code{<stdio.h>} is automatically included
-and @code{YYFPRINTF} is defined to @code{fprintf}.
+@example
+@group
+expr: @dots{}
+ | '(' expr ')'
+ @{ $$ = $2; @}
+ | '(' error ')'
+ @dots{}
+@end group
+@end example
-Once you have compiled the program with trace facilities, the way to
-request a trace is to store a nonzero value in the variable @code{yydebug}.
-You can do this by making the C code do it (in @code{main}, perhaps), or
-you can alter the value with a C debugger.
+If this rule acts within the @code{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 @code{hex} construct should be parsed with the flag still in effect.
-Each step taken by the parser when @code{yydebug} is nonzero produces a
-line or two of trace information, written on @code{stderr}. The trace
-messages tell you these things:
+What if there is an error recovery rule which might abort out of the
+@code{hex} construct or might not, depending on circumstances? There is no
+way you can write the action to determine whether a @code{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.
-@itemize @bullet
-@item
-Each time the parser calls @code{yylex}, what kind of token was read.
+@c ================================================== Debugging Your Parser
-@item
-Each time a token is shifted, the depth and complete contents of the
-state stack (@pxref{Parser States}).
+@node Debugging
+@chapter Debugging Your Parser
-@item
-Each time a rule is reduced, which rule it is, and the complete contents
-of the state stack afterward.
-@end itemize
+Developing a parser can be a challenge, especially if you don't
+understand the algorithm (@pxref{Algorithm, ,The Bison Parser
+Algorithm}). Even so, sometimes a detailed description of the automaton
+can help (@pxref{Understanding, , Understanding Your Parser}), or
+tracing the execution of the parser can give some insight on why it
+behaves improperly (@pxref{Tracing, , Tracing Your Parser}).
-To make sense of this information, it helps to refer to the listing file
-produced by the Bison @samp{-v} option (@pxref{Invocation, ,Invoking
-Bison}). 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.
+@menu
+* Understanding:: Understanding the structure of your parser.
+* Tracing:: Tracing the execution of your parser.
+@end menu
-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.
+@node Understanding
+@section Understanding Your Parser
-@findex YYPRINT
-The debugging information normally gives the token type of each token
-read, but not its semantic value. You can optionally define a macro
-named @code{YYPRINT} to provide a way to print the value. If you define
-@code{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 @code{yylval}).
+As documented elsewhere (@pxref{Algorithm, ,The Bison Parser Algorithm})
+Bison parsers are @dfn{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).
-Here is an example of @code{YYPRINT} suitable for the multi-function
-calculator (@pxref{Mfcalc Decl, ,Declarations for @code{mfcalc}}):
+The textual file is generated when the options @option{--report} or
+@option{--verbose} are specified, see @xref{Invocation, , Invoking
+Bison}. Its name is made by removing @samp{.tab.c} or @samp{.c} from
+the parser output file name, and adding @samp{.output} instead.
+Therefore, if the input file is @file{foo.y}, then the parser file is
+called @file{foo.tab.c} by default. As a consequence, the verbose
+output file is called @file{foo.output}.
-@smallexample
-%@{
- static void print_token_value (FILE *, int, YYSTYPE);
- #define YYPRINT(file, type, value) print_token_value (file, type, value)
-%@}
+The following grammar file, @file{calc.y}, will be used in the sequel:
-@dots{} %% @dots{} %% @dots{}
+@example
+%token NUM STR
+%left '+' '-'
+%left '*'
+%%
+exp: exp '+' exp
+ | exp '-' exp
+ | exp '*' exp
+ | exp '/' exp
+ | NUM
+ ;
+useless: STR;
+%%
+@end example
-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);
-@}
-@end smallexample
+@command{bison} reports:
-@c ================================================= Invoking Bison
+@example
+calc.y: warning: 1 nonterminal useless in grammar
+calc.y: warning: 1 rule useless in grammar
+calc.y:11.1-7: warning: nonterminal useless in grammar: useless
+calc.y:11.10-12: warning: rule useless in grammar: useless: STR
+calc.y: conflicts: 7 shift/reduce
+@end example
-@node Invocation
-@chapter Invoking Bison
-@cindex invoking Bison
-@cindex Bison invocation
-@cindex options for invoking Bison
+When given @option{--report=state}, in addition to @file{calc.tab.c}, it
+creates a file @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 usual way to invoke Bison is as follows:
+The first section includes details on conflicts that were solved thanks
+to precedence and/or associativity:
@example
-bison @var{infile}
+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.
+@exdent @dots{}
@end example
-Here @var{infile} is the grammar file name, which usually ends in
-@samp{.y}. The parser file's name is made by replacing the @samp{.y}
-with @samp{.tab.c} and removing any leading directory. Thus, the
-@samp{bison foo.y} file name yields
-@file{foo.tab.c}, and the @samp{bison hack/foo.y} file name yields
-@file{foo.tab.c}. It's also possible, in case you are writing
-C++ code instead of C in your grammar file, to name it @file{foo.ypp}
-or @file{foo.y++}. Then, the output files will take an extension like
-the given one as input (respectively @file{foo.tab.cpp} and
-@file{foo.tab.c++}).
-This feature takes effect with all options that manipulate file names like
-@samp{-o} or @samp{-d}.
-
-For example :
+@noindent
+The next section lists states that still have conflicts.
@example
-bison -d @var{infile.yxx}
+State 8 conflicts: 1 shift/reduce
+State 9 conflicts: 1 shift/reduce
+State 10 conflicts: 1 shift/reduce
+State 11 conflicts: 4 shift/reduce
@end example
+
@noindent
-will produce @file{infile.tab.cxx} and @file{infile.tab.hxx}, and
+@cindex token, useless
+@cindex useless token
+@cindex nonterminal, useless
+@cindex useless nonterminal
+@cindex rule, useless
+@cindex useless rule
+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):
@example
-bison -d -o @var{output.c++} @var{infile.y}
-@end example
-@noindent
-will produce @file{output.c++} and @file{outfile.h++}.
+Nonterminals useless in grammar:
+ useless
-For compatibility with @acronym{POSIX}, the standard Bison
-distribution also contains a shell script called @command{yacc} that
-invokes Bison with the @option{-y} option.
+Terminals unused in grammar:
+ STR
-@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 @code{yylex} and @code{main}.
-@end menu
+Rules useless in grammar:
+#6 useless: STR;
+@end example
-@node Bison Options
-@section Bison Options
+@noindent
+The next section reproduces the exact grammar that Bison used:
-Bison supports both traditional single-letter options and mnemonic long
-option names. Long option names are indicated with @samp{--} instead of
-@samp{-}. Abbreviations for option names are allowed as long as they
-are unique. When a long option takes an argument, like
-@samp{--file-prefix}, connect the option name and the argument with
-@samp{=}.
+@example
+Grammar
-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.
+ 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
+@end example
-@c Please, keep this ordered as in `bison --help'.
@noindent
-Operations modes:
-@table @option
-@item -h
-@itemx --help
-Print a summary of the command-line options to Bison and exit.
+and reports the uses of the symbols:
-@item -V
-@itemx --version
-Print the version number of Bison and exit.
+@example
+Terminals, with rules where they appear
-@item --print-localedir
-Print the name of the directory containing locale-dependent data.
+$end (0) 0
+'*' (42) 3
+'+' (43) 1
+'-' (45) 2
+'/' (47) 4
+error (256)
+NUM (258) 5
-@item -y
-@itemx --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
-@file{y.tab.c}, and the other outputs are called @file{y.output} and
-@file{y.tab.h}.
-Also, if generating an @acronym{LALR}(1) parser in C, generate @code{#define}
-statements in addition to an @code{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 @acronym{POSIX}:
+Nonterminals, with rules where they appear
-@example
-#! /bin/sh
-bison -y "$@@"
+$accept (8)
+ on left: 0
+exp (9)
+ on left: 1 2 3 4 5, on right: 0 1 2 3 4
@end example
-The @option{-y}/@option{--yacc} option is intended for use with
-traditional Yacc grammars. If your grammar uses a Bison extension
-like @samp{%glr-parser}, Bison might not be Yacc-compatible even if
-this option is specified.
-
-@end table
-
@noindent
-Tuning the parser:
-
-@table @option
-@item -t
-@itemx --debug
-In the parser file, define the macro @code{YYDEBUG} to 1 if it is not
-already defined, so that the debugging facilities are compiled.
-@xref{Tracing, ,Tracing Your Parser}.
+@cindex item
+@cindex pointed rule
+@cindex rule, pointed
+Bison then proceeds onto the automaton itself, describing each state
+with it set of @dfn{items}, also known as @dfn{pointed rules}. Each
+item is a production rule together with a point (marked by @samp{.})
+that the input cursor.
-@item -L @var{language}
-@itemx --language=@var{language}
-Specify the programming language for the generated parser, as if
-@code{%language} was specified (@pxref{Decl Summary, , Bison Declaration
-Summary}). Currently supported languages include C and C++.
-@var{language} is case-insensitive.
+@example
+state 0
-@item --locations
-Pretend that @code{%locations} was specified. @xref{Decl Summary}.
+ $accept -> . exp $ (rule 0)
-@item -p @var{prefix}
-@itemx --name-prefix=@var{prefix}
-Pretend that @code{%name-prefix "@var{prefix}"} was specified.
-@xref{Decl Summary}.
+ NUM shift, and go to state 1
-@item -l
-@itemx --no-lines
-Don't put any @code{#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.
+ exp go to state 2
+@end example
-@item -n
-@itemx --no-parser
-Pretend that @code{%no-parser} was specified. @xref{Decl Summary}.
+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, @code{exp}). When the parser returns to this state right
+after having reduced a rule that produced an @code{exp}, the control
+flow jumps to state 2. If there is no such transition on a nonterminal
+symbol, and the lookahead is a @code{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.''
-@item -S @var{file}
-@itemx --skeleton=@var{file}
-Specify the skeleton to use, as if @code{%skeleton} was specified
-(@pxref{Decl Summary, , Bison Declaration Summary}).
+@cindex core, item set
+@cindex item set core
+@cindex kernel, item set
+@cindex item set core
+Even though the only active rule in state 0 seems to be rule 0, the
+report lists @code{NUM} as a lookahead token because @code{NUM} can be
+at the beginning of any rule deriving an @code{exp}. By default Bison
+reports the so-called @dfn{core} or @dfn{kernel} of the item set, but if
+you want to see more detail you can invoke @command{bison} with
+@option{--report=itemset} to list all the items, include those that can
+be derived:
-You probably don't need this option unless you are developing Bison;
-you should use @option{--language} if you want to specify the skeleton for a
-different language, because it is clearer and because it will always
-choose the correct skeleton for non-deterministic or push parsers.
+@example
+state 0
-@item -k
-@itemx --token-table
-Pretend that @code{%token-table} was specified. @xref{Decl Summary}.
-@end table
+ $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)
-@noindent
-Adjust the output:
+ NUM shift, and go to state 1
-@table @option
-@item -d
-@itemx --defines
-Pretend that @code{%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. @xref{Decl Summary}.
+ exp go to state 2
+@end example
-@item --defines=@var{defines-file}
-Same as above, but save in the file @var{defines-file}.
+@noindent
+In the state 1...
-@item -b @var{file-prefix}
-@itemx --file-prefix=@var{prefix}
-Pretend that @code{%file-prefix} was specified, i.e., specify prefix to use
-for all Bison output file names. @xref{Decl Summary}.
+@example
+state 1
-@item -r @var{things}
-@itemx --report=@var{things}
-Write an extra output file containing verbose description of the comma
-separated list of @var{things} among:
+ exp -> NUM . (rule 5)
-@table @code
-@item state
-Description of the grammar, conflicts (resolved and unresolved), and
-@acronym{LALR} automaton.
+ $default reduce using rule 5 (exp)
+@end example
-@item lookahead
-Implies @code{state} and augments the description of the automaton with
-each rule's lookahead set.
+@noindent
+the rule 5, @samp{exp: NUM;}, is completed. Whatever the lookahead token
+(@samp{$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 (@samp{exp: go to state 2}).
-@item itemset
-Implies @code{state} and augments the description of the automaton with
-the full set of items for each state, instead of its core only.
-@end table
+@example
+state 2
-@item -v
-@itemx --verbose
-Pretend that @code{%verbose} was specified, i.e., write an extra output
-file containing verbose descriptions of the grammar and
-parser. @xref{Decl Summary}.
+ $accept -> exp . $ (rule 0)
+ exp -> exp . '+' exp (rule 1)
+ exp -> exp . '-' exp (rule 2)
+ exp -> exp . '*' exp (rule 3)
+ exp -> exp . '/' exp (rule 4)
-@item -o @var{file}
-@itemx --output=@var{file}
-Specify the @var{file} for the parser file.
+ $ 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
+@end example
-The other output files' names are constructed from @var{file} as
-described under the @samp{-v} and @samp{-d} options.
-
-@item -g
-Output a graphical representation of the @acronym{LALR}(1) grammar
-automaton computed by Bison, in @uref{http://www.graphviz.org/, Graphviz}
-@uref{http://www.graphviz.org/doc/info/lang.html, @acronym{DOT}} format.
-If the grammar file is @file{foo.y}, the output file will
-be @file{foo.dot}.
+@noindent
+In state 2, the automaton can only shift a symbol. For instance,
+because of the item @samp{exp -> exp . '+' exp}, if the lookahead if
+@samp{+}, it will be shifted on the parse stack, and the automaton
+control will jump to state 4, corresponding to the item @samp{exp -> exp
+'+' . exp}. Since there is no default action, any other token than
+those listed above will trigger a syntax error.
-@item --graph=@var{graph-file}
-The behavior of @var{--graph} is the same than @samp{-g}. The only
-difference is that it has an optional argument which is the name of
-the output graph file.
-@end table
+@cindex accepting state
+The state 3 is named the @dfn{final state}, or the @dfn{accepting
+state}:
-@node Option Cross Key
-@section Option Cross Key
+@example
+state 3
-@c FIXME: How about putting the directives too?
-Here is a list of options, alphabetized by long option, to help you find
-the corresponding short option.
-
-@multitable {@option{--defines=@var{defines-file}}} {@option{-b @var{file-prefix}XXX}}
-@headitem Long Option @tab Short Option
-@item @option{--debug} @tab @option{-t}
-@item @option{--defines=@var{defines-file}} @tab @option{-d}
-@item @option{--file-prefix=@var{prefix}} @tab @option{-b @var{file-prefix}}
-@item @option{--graph=@var{graph-file}} @tab @option{-d}
-@item @option{--help} @tab @option{-h}
-@item @option{--name-prefix=@var{prefix}} @tab @option{-p @var{name-prefix}}
-@item @option{--no-lines} @tab @option{-l}
-@item @option{--no-parser} @tab @option{-n}
-@item @option{--output=@var{outfile}} @tab @option{-o @var{outfile}}
-@item @option{--print-localedir} @tab
-@item @option{--token-table} @tab @option{-k}
-@item @option{--verbose} @tab @option{-v}
-@item @option{--version} @tab @option{-V}
-@item @option{--yacc} @tab @option{-y}
-@end multitable
+ $accept -> exp $ . (rule 0)
-@node Yacc Library
-@section Yacc Library
+ $default accept
+@end example
-The Yacc library contains default implementations of the
-@code{yyerror} and @code{main} functions. These default
-implementations are normally not useful, but @acronym{POSIX} requires
-them. To use the Yacc library, link your program with the
-@option{-ly} option. Note that Bison's implementation of the Yacc
-library is distributed under the terms of the @acronym{GNU} General
-Public License (@pxref{Copying}).
+@noindent
+the initial rule is completed (the start symbol and the end
+of input were read), the parsing exits successfully.
-If you use the Yacc library's @code{yyerror} function, you should
-declare @code{yyerror} as follows:
+The interpretation of states 4 to 7 is straightforward, and is left to
+the reader.
@example
-int yyerror (char const *);
-@end example
+state 4
-Bison ignores the @code{int} value returned by this @code{yyerror}.
-If you use the Yacc library's @code{main} function, your
-@code{yyparse} function should have the following type signature:
+ exp -> exp '+' . exp (rule 1)
-@example
-int yyparse (void);
-@end example
+ NUM shift, and go to state 1
-@c ================================================= C++ Bison
+ exp go to state 8
-@node C++ Language Interface
-@chapter C++ Language Interface
+state 5
-@menu
-* C++ Parsers:: The interface to generate C++ parser classes
-* A Complete C++ Example:: Demonstrating their use
-@end menu
+ exp -> exp '-' . exp (rule 2)
-@node C++ Parsers
-@section C++ Parsers
+ NUM shift, and go to state 1
-@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
-@end menu
+ exp go to state 9
-@node C++ Bison Interface
-@subsection C++ Bison Interface
-@c - %language "C++"
-@c - Always pure
-@c - initial action
+state 6
-The C++ @acronym{LALR}(1) parser is selected using the language directive,
-@samp{%language "C++"}, or the synonymous command-line option
-@option{--language=c++}.
-@xref{Decl Summary}.
+ exp -> exp '*' . exp (rule 3)
-When run, @command{bison} will create several
-entities in the @samp{yy} namespace. Use the @samp{%name-prefix}
-directive to change the namespace name, see @ref{Decl Summary}. The
-various classes are generated in the following files:
+ NUM shift, and go to state 1
-@table @file
-@item position.hh
-@itemx location.hh
-The definition of the classes @code{position} and @code{location},
-used for location tracking. @xref{C++ Location Values}.
+ exp go to state 10
-@item stack.hh
-An auxiliary class @code{stack} used by the parser.
+state 7
-@item @var{file}.hh
-@itemx @var{file}.cc
-(Assuming the extension of the input file was @samp{.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 (@pxref{Invocation}).
+ exp -> exp '/' . exp (rule 4)
-The header is @emph{mandatory}; you must either pass
-@option{-d}/@option{--defines} to @command{bison}, or use the
-@samp{%defines} directive.
-@end table
+ NUM shift, and go to state 1
-All these files are documented using Doxygen; run @command{doxygen}
-for a complete and accurate documentation.
+ exp go to state 11
+@end example
-@node C++ Semantic Values
-@subsection C++ Semantic Values
-@c - No objects in unions
-@c - YYSTYPE
-@c - Printer and destructor
+As was announced in beginning of the report, @samp{State 8 conflicts:
+1 shift/reduce}:
-The @code{%union} directive works as for C, see @ref{Union Decl, ,The
-Collection of Value Types}. In particular it produces a genuine
-@code{union}@footnote{In the future techniques to allow complex types
-within pseudo-unions (similar to Boost variants) might be implemented to
-alleviate these issues.}, which have a few specific features in C++.
-@itemize @minus
-@item
-The type @code{YYSTYPE} is defined but its use is discouraged: rather
-you should refer to the parser's encapsulated type
-@code{yy::parser::semantic_type}.
-@item
-Non POD (Plain Old Data) types cannot be used. C++ forbids any
-instance of classes with constructors in unions: only @emph{pointers}
-to such objects are allowed.
-@end itemize
+@example
+state 8
-Because objects have to be stored via pointers, memory is not
-reclaimed automatically: using the @code{%destructor} directive is the
-only means to avoid leaks. @xref{Destructor Decl, , Freeing Discarded
-Symbols}.
+ 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
-@node C++ Location Values
-@subsection C++ Location Values
-@c - %locations
-@c - class Position
-@c - class Location
-@c - %define filename_type "const symbol::Symbol"
+ '/' [reduce using rule 1 (exp)]
+ $default reduce using rule 1 (exp)
+@end example
-When the directive @code{%locations} is used, the C++ parser supports
-location tracking, see @ref{Locations, , Locations Overview}. Two
-auxiliary classes define a @code{position}, a single point in a file,
-and a @code{location}, a range composed of a pair of
-@code{position}s (possibly spanning several files).
+Indeed, there are two actions associated to the lookahead @samp{/}:
+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 @samp{/}, the
+sentence @samp{NUM + NUM / NUM} can be parsed as @samp{NUM + (NUM /
+NUM)}, which corresponds to shifting @samp{/}, or as @samp{(NUM + NUM) /
+NUM}, which corresponds to reducing rule 1.
-@deftypemethod {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 @samp{@var{type}*} using @samp{%define
-filename_type "@var{type}"}.
-@end deftypemethod
+Because in deterministic parsing a single decision can be made, Bison
+arbitrarily chose to disable the reduction, see @ref{Shift/Reduce, ,
+Shift/Reduce Conflicts}. Discarded actions are reported in between
+square brackets.
-@deftypemethod {position} {unsigned int} line
-The line, starting at 1.
-@end deftypemethod
+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
+@emph{and} reducing is possible or when @emph{several} reductions are
+possible, the lookahead is required to select the action. State 8 is
+one such state: if the lookahead is @samp{*} or @samp{/} 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 @samp{*}, since we specified that @samp{*} has higher
+precedence than @samp{+}. More generally, some items are eligible only
+with some set of possible lookahead tokens. When run with
+@option{--report=lookahead}, Bison specifies these lookahead tokens:
-@deftypemethod {position} {unsigned int} lines (int @var{height} = 1)
-Advance by @var{height} lines, resetting the column number.
-@end deftypemethod
+@example
+state 8
-@deftypemethod {position} {unsigned int} column
-The column, starting at 0.
-@end deftypemethod
+ 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)
-@deftypemethod {position} {unsigned int} columns (int @var{width} = 1)
-Advance by @var{width} columns, without changing the line number.
-@end deftypemethod
+ '*' shift, and go to state 6
+ '/' shift, and go to state 7
-@deftypemethod {position} {position&} operator+= (position& @var{pos}, int @var{width})
-@deftypemethodx {position} {position} operator+ (const position& @var{pos}, int @var{width})
-@deftypemethodx {position} {position&} operator-= (const position& @var{pos}, int @var{width})
-@deftypemethodx {position} {position} operator- (position& @var{pos}, int @var{width})
-Various forms of syntactic sugar for @code{columns}.
-@end deftypemethod
+ '/' [reduce using rule 1 (exp)]
+ $default reduce using rule 1 (exp)
+@end example
-@deftypemethod {position} {position} operator<< (std::ostream @var{o}, const position& @var{p})
-Report @var{p} on @var{o} like this:
-@samp{@var{file}:@var{line}.@var{column}}, or
-@samp{@var{line}.@var{column}} if @var{file} is null.
-@end deftypemethod
+The remaining states are similar:
-@deftypemethod {location} {position} begin
-@deftypemethodx {location} {position} end
-The first, inclusive, position of the range, and the first beyond.
-@end deftypemethod
+@example
+state 9
-@deftypemethod {location} {unsigned int} columns (int @var{width} = 1)
-@deftypemethodx {location} {unsigned int} lines (int @var{height} = 1)
-Advance the @code{end} position.
-@end deftypemethod
+ 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)
-@deftypemethod {location} {location} operator+ (const location& @var{begin}, const location& @var{end})
-@deftypemethodx {location} {location} operator+ (const location& @var{begin}, int @var{width})
-@deftypemethodx {location} {location} operator+= (const location& @var{loc}, int @var{width})
-Various forms of syntactic sugar.
-@end deftypemethod
+ '*' shift, and go to state 6
+ '/' shift, and go to state 7
-@deftypemethod {location} {void} step ()
-Move @code{begin} onto @code{end}.
-@end deftypemethod
+ '/' [reduce using rule 2 (exp)]
+ $default reduce using rule 2 (exp)
+state 10
-@node C++ Parser Interface
-@subsection C++ Parser Interface
-@c - define parser_class_name
-@c - Ctor
-@c - parse, error, set_debug_level, debug_level, set_debug_stream,
-@c debug_stream.
-@c - Reporting errors
+ 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)
+@end example
+
+@noindent
+Observe that state 11 contains conflicts not only due to the lack of
+precedence of @samp{/} with respect to @samp{+}, @samp{-}, and
+@samp{*}, but also because the
+associativity of @samp{/} is not specified.
+
+
+@node Tracing
+@section Tracing Your Parser
+@findex yydebug
+@cindex debugging
+@cindex tracing the parser
+
+If a Bison grammar compiles properly but doesn't do what you want when it
+runs, the @code{yydebug} parser-trace feature can help you figure out why.
+
+There are several means to enable compilation of trace facilities:
+
+@table @asis
+@item the macro @code{YYDEBUG}
+@findex YYDEBUG
+Define the macro @code{YYDEBUG} to a nonzero value when you compile the
+parser. This is compliant with @acronym{POSIX} Yacc. You could use
+@samp{-DYYDEBUG=1} as a compiler option or you could put @samp{#define
+YYDEBUG 1} in the prologue of the grammar file (@pxref{Prologue, , The
+Prologue}).
+
+@item the option @option{-t}, @option{--debug}
+Use the @samp{-t} option when you run Bison (@pxref{Invocation,
+,Invoking Bison}). This is @acronym{POSIX} compliant too.
+
+@item the directive @samp{%debug}
+@findex %debug
+Add the @code{%debug} directive (@pxref{Decl Summary, ,Bison Declaration
+Summary}). This Bison extension is maintained for backward
+compatibility with previous versions of Bison.
+
+@item the variable @samp{parse.trace}
+@findex %define parse.trace
+Add the @samp{%define parse.trace} directive (@pxref{Decl Summary,
+,Bison Declaration Summary}), or pass the @option{-Dparse.trace} option
+(@pxref{Bison Options}). This is a Bison extension, which is especially
+useful for languages that don't use a preprocessor. Unless
+@acronym{POSIX} and Yacc portability matter to you, this is the
+preferred solution.
+@end table
+
+We suggest that you always enable the trace option so that debugging is
+always possible.
+
+The trace facility outputs messages with macro calls of the form
+@code{YYFPRINTF (stderr, @var{format}, @var{args})} where
+@var{format} and @var{args} are the usual @code{printf} format and variadic
+arguments. If you define @code{YYDEBUG} to a nonzero value but do not
+define @code{YYFPRINTF}, @code{<stdio.h>} is automatically included
+and @code{YYFPRINTF} is defined to @code{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 @code{yydebug}.
+You can do this by making the C code do it (in @code{main}, perhaps), or
+you can alter the value with a C debugger.
+
+Each step taken by the parser when @code{yydebug} is nonzero produces a
+line or two of trace information, written on @code{stderr}. The trace
+messages tell you these things:
+
+@itemize @bullet
+@item
+Each time the parser calls @code{yylex}, what kind of token was read.
+
+@item
+Each time a token is shifted, the depth and complete contents of the
+state stack (@pxref{Parser States}).
+
+@item
+Each time a rule is reduced, which rule it is, and the complete contents
+of the state stack afterward.
+@end itemize
+
+To make sense of this information, it helps to refer to the listing file
+produced by the Bison @samp{-v} option (@pxref{Invocation, ,Invoking
+Bison}). 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.
+
+@findex YYPRINT
+The debugging information normally gives the token type of each token
+read, but not its semantic value. You can optionally define a macro
+named @code{YYPRINT} to provide a way to print the value. If you define
+@code{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 @code{yylval}).
+
+Here is an example of @code{YYPRINT} suitable for the multi-function
+calculator (@pxref{Mfcalc Declarations, ,Declarations for @code{mfcalc}}):
+
+@smallexample
+%@{
+ static void print_token_value (FILE *, int, YYSTYPE);
+ #define YYPRINT(file, type, value) print_token_value (file, type, value)
+%@}
+
+@dots{} %% @dots{} %% @dots{}
+
+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);
+@}
+@end smallexample
+
+@c ================================================= Invoking Bison
+
+@node Invocation
+@chapter Invoking Bison
+@cindex invoking Bison
+@cindex Bison invocation
+@cindex options for invoking Bison
+
+The usual way to invoke Bison is as follows:
+
+@example
+bison @var{infile}
+@end example
+
+Here @var{infile} is the grammar file name, which usually ends in
+@samp{.y}. The parser file's name is made by replacing the @samp{.y}
+with @samp{.tab.c} and removing any leading directory. Thus, the
+@samp{bison foo.y} file name yields
+@file{foo.tab.c}, and the @samp{bison hack/foo.y} file name yields
+@file{foo.tab.c}. It's also possible, in case you are writing
+C++ code instead of C in your grammar file, to name it @file{foo.ypp}
+or @file{foo.y++}. Then, the output files will take an extension like
+the given one as input (respectively @file{foo.tab.cpp} and
+@file{foo.tab.c++}).
+This feature takes effect with all options that manipulate file names like
+@samp{-o} or @samp{-d}.
+
+For example :
+
+@example
+bison -d @var{infile.yxx}
+@end example
+@noindent
+will produce @file{infile.tab.cxx} and @file{infile.tab.hxx}, and
+
+@example
+bison -d -o @var{output.c++} @var{infile.y}
+@end example
+@noindent
+will produce @file{output.c++} and @file{outfile.h++}.
+
+For compatibility with @acronym{POSIX}, the standard Bison
+distribution also contains a shell script called @command{yacc} that
+invokes Bison with the @option{-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 @code{yylex} and @code{main}.
+@end menu
+
+@node Bison Options
+@section Bison Options
+
+Bison supports both traditional single-letter options and mnemonic long
+option names. Long option names are indicated with @samp{--} instead of
+@samp{-}. Abbreviations for option names are allowed as long as they
+are unique. When a long option takes an argument, like
+@samp{--file-prefix}, connect the option name and the argument with
+@samp{=}.
+
+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.
+
+@c Please, keep this ordered as in `bison --help'.
+@noindent
+Operations modes:
+@table @option
+@item -h
+@itemx --help
+Print a summary of the command-line options to Bison and exit.
+
+@item -V
+@itemx --version
+Print the version number of Bison and exit.
+
+@item --print-localedir
+Print the name of the directory containing locale-dependent data.
+
+@item --print-datadir
+Print the name of the directory containing skeletons and XSLT.
+
+@item -y
+@itemx --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
+@file{y.tab.c}, and the other outputs are called @file{y.output} and
+@file{y.tab.h}.
+Also, if generating a deterministic parser in C, generate @code{#define}
+statements in addition to an @code{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 @acronym{POSIX}:
+
+@example
+#! /bin/sh
+bison -y "$@@"
+@end example
+
+The @option{-y}/@option{--yacc} option is intended for use with
+traditional Yacc grammars. If your grammar uses a Bison extension
+like @samp{%glr-parser}, Bison might not be Yacc-compatible even if
+this option is specified.
+
+@item -W [@var{category}]
+@itemx --warnings[=@var{category}]
+Output warnings falling in @var{category}. @var{category} can be one
+of:
+@table @code
+@item 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 @code{$2} in:
+
+@example
+exp: '1' @{ $$ = 1; @} '+' exp @{ $$ = $1 + $4; @};
+@end example
+
+Also warn about mid-rule values that are used but not set.
+For example, warn about unset @code{$$} in the mid-rule action in:
+
+@example
+ exp: '1' @{ $1 = 1; @} '+' exp @{ $$ = $2 + $4; @};
+@end example
+
+These warnings are not enabled by default since they sometimes prove to
+be false alarms in existing grammars employing the Yacc constructs
+@code{$0} or @code{$-@var{n}} (where @var{n} is some positive integer).
+
+
+@item yacc
+Incompatibilities with @acronym{POSIX} Yacc.
+
+@item all
+All the warnings.
+@item none
+Turn off all the warnings.
+@item error
+Treat warnings as errors.
+@end table
+
+A category can be turned off by prefixing its name with @samp{no-}. For
+instance, @option{-Wno-syntax} will hide the warnings about unused
+variables.
+@end table
+
+@noindent
+Tuning the parser:
+
+@table @option
+@item -t
+@itemx --debug
+In the parser file, define the macro @code{YYDEBUG} to 1 if it is not
+already defined, so that the debugging facilities are compiled.
+@xref{Tracing, ,Tracing Your Parser}.
+
+@item -D @var{name}[=@var{value}]
+@itemx --define=@var{name}[=@var{value}]
+@itemx -F @var{name}[=@var{value}]
+@itemx --force-define=@var{name}[=@var{value}]
+Each of these is equivalent to @samp{%define @var{name} "@var{value}"}
+(@pxref{Decl Summary, ,%define}) except that Bison processes multiple
+definitions for the same @var{name} as follows:
+
+@itemize
+@item
+Bison quietly ignores all command-line definitions for @var{name} except
+the last.
+@item
+If that command-line definition is specified by a @code{-D} or
+@code{--define}, Bison reports an error for any @code{%define}
+definition for @var{name}.
+@item
+If that command-line definition is specified by a @code{-F} or
+@code{--force-define} instead, Bison quietly ignores all @code{%define}
+definitions for @var{name}.
+@item
+Otherwise, Bison reports an error if there are multiple @code{%define}
+definitions for @var{name}.
+@end itemize
+
+You should avoid using @code{-F} and @code{--force-define} in your
+makefiles unless you are confident that it is safe to quietly ignore any
+conflicting @code{%define} that may be added to the grammar file.
+
+@item -L @var{language}
+@itemx --language=@var{language}
+Specify the programming language for the generated parser, as if
+@code{%language} was specified (@pxref{Decl Summary, , Bison Declaration
+Summary}). Currently supported languages include C, C++, and Java.
+@var{language} is case-insensitive.
+
+This option is experimental and its effect may be modified in future
+releases.
+
+@item --locations
+Pretend that @code{%locations} was specified. @xref{Decl Summary}.
+
+@item -p @var{prefix}
+@itemx --name-prefix=@var{prefix}
+Pretend that @code{%name-prefix "@var{prefix}"} was specified.
+@xref{Decl Summary}.
+
+@item -l
+@itemx --no-lines
+Don't put any @code{#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.
+
+@item -S @var{file}
+@itemx --skeleton=@var{file}
+Specify the skeleton to use, similar to @code{%skeleton}
+(@pxref{Decl Summary, , Bison Declaration Summary}).
+
+@c You probably don't need this option unless you are developing Bison.
+@c You should use @option{--language} if you want to specify the skeleton for a
+@c different language, because it is clearer and because it will always
+@c choose the correct skeleton for non-deterministic or push parsers.
+
+If @var{file} does not contain a @code{/}, @var{file} is the name of a skeleton
+file in the Bison installation directory.
+If it does, @var{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.
+
+@item -k
+@itemx --token-table
+Pretend that @code{%token-table} was specified. @xref{Decl Summary}.
+@end table
+
+@noindent
+Adjust the output:
+
+@table @option
+@item --defines[=@var{file}]
+Pretend that @code{%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. @xref{Decl Summary}.
+
+@item -d
+This is the same as @code{--defines} except @code{-d} does not accept a
+@var{file} argument since POSIX Yacc requires that @code{-d} can be bundled
+with other short options.
+
+@item -b @var{file-prefix}
+@itemx --file-prefix=@var{prefix}
+Pretend that @code{%file-prefix} was specified, i.e., specify prefix to use
+for all Bison output file names. @xref{Decl Summary}.
+
+@item -r @var{things}
+@itemx --report=@var{things}
+Write an extra output file containing verbose description of the comma
+separated list of @var{things} among:
+
+@table @code
+@item state
+Description of the grammar, conflicts (resolved and unresolved), and
+parser's automaton.
+
+@item lookahead
+Implies @code{state} and augments the description of the automaton with
+each rule's lookahead set.
+
+@item itemset
+Implies @code{state} and augments the description of the automaton with
+the full set of items for each state, instead of its core only.
+@end table
+
+@item --report-file=@var{file}
+Specify the @var{file} for the verbose description.
+
+@item -v
+@itemx --verbose
+Pretend that @code{%verbose} was specified, i.e., write an extra output
+file containing verbose descriptions of the grammar and
+parser. @xref{Decl Summary}.
+
+@item -o @var{file}
+@itemx --output=@var{file}
+Specify the @var{file} for the parser file.
+
+The other output files' names are constructed from @var{file} as
+described under the @samp{-v} and @samp{-d} options.
+
+@item -g [@var{file}]
+@itemx --graph[=@var{file}]
+Output a graphical representation of the parser's
+automaton computed by Bison, in @uref{http://www.graphviz.org/, Graphviz}
+@uref{http://www.graphviz.org/doc/info/lang.html, @acronym{DOT}} format.
+@code{@var{file}} is optional.
+If omitted and the grammar file is @file{foo.y}, the output file will be
+@file{foo.dot}.
+
+@item -x [@var{file}]
+@itemx --xml[=@var{file}]
+Output an XML report of the parser's automaton computed by Bison.
+@code{@var{file}} is optional.
+If omitted and the grammar file is @file{foo.y}, the output file will be
+@file{foo.xml}.
+(The current XML schema is experimental and may evolve.
+More user feedback will help to stabilize it.)
+@end table
+
+@node Option Cross Key
+@section Option Cross Key
+
+Here is a list of options, alphabetized by long option, to help you find
+the corresponding short option and directive.
+
+@multitable {@option{--force-define=@var{name}[=@var{value}]}} {@option{-F @var{name}[=@var{value}]}} {@code{%nondeterministic-parser}}
+@headitem Long Option @tab Short Option @tab Bison Directive
+@include cross-options.texi
+@end multitable
+
+@node Yacc Library
+@section Yacc Library
+
+The Yacc library contains default implementations of the
+@code{yyerror} and @code{main} functions. These default
+implementations are normally not useful, but @acronym{POSIX} requires
+them. To use the Yacc library, link your program with the
+@option{-ly} option. Note that Bison's implementation of the Yacc
+library is distributed under the terms of the @acronym{GNU} General
+Public License (@pxref{Copying}).
+
+If you use the Yacc library's @code{yyerror} function, you should
+declare @code{yyerror} as follows:
+
+@example
+int yyerror (char const *);
+@end example
+
+Bison ignores the @code{int} value returned by this @code{yyerror}.
+If you use the Yacc library's @code{main} function, your
+@code{yyparse} function should have the following type signature:
+
+@example
+int yyparse (void);
+@end example
+
+@c ================================================= C++ Bison
+
+@node Other Languages
+@chapter Parsers Written In Other Languages
+
+@menu
+* C++ Parsers:: The interface to generate C++ parser classes
+* Java Parsers:: The interface to generate Java parser classes
+@end menu
+
+@node C++ Parsers
+@section 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
+@end menu
+
+@node C++ Bison Interface
+@subsection C++ Bison Interface
+@c - %skeleton "lalr1.cc"
+@c - Always pure
+@c - initial action
+
+The C++ deterministic parser is selected using the skeleton directive,
+@samp{%skeleton "lalr1.c"}, or the synonymous command-line option
+@option{--skeleton=lalr1.c}.
+@xref{Decl Summary}.
+
+When run, @command{bison} will create several entities in the @samp{yy}
+namespace.
+@findex %define api.namespace
+Use the @samp{%define api.namespace} directive to change the namespace
+name, see
+@ref{Decl Summary}.
+The various classes are generated in the following files:
+
+@table @file
+@item position.hh
+@itemx location.hh
+The definition of the classes @code{position} and @code{location},
+used for location tracking. @xref{C++ Location Values}.
+
+@item stack.hh
+An auxiliary class @code{stack} used by the parser.
+
+@item @var{file}.hh
+@itemx @var{file}.cc
+(Assuming the extension of the input file was @samp{.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 (@pxref{Invocation}).
+
+The header is @emph{mandatory}; you must either pass
+@option{-d}/@option{--defines} to @command{bison}, or use the
+@samp{%defines} directive.
+@end table
+
+All these files are documented using Doxygen; run @command{doxygen}
+for a complete and accurate documentation.
+
+@node C++ Semantic Values
+@subsection C++ Semantic Values
+@c - No objects in unions
+@c - YYSTYPE
+@c - Printer and destructor
+
+The @code{%union} directive works as for C, see @ref{Union Decl, ,The
+Collection of Value Types}. In particular it produces a genuine
+@code{union}@footnote{In the future techniques to allow complex types
+within pseudo-unions (similar to Boost variants) might be implemented to
+alleviate these issues.}, which have a few specific features in C++.
+@itemize @minus
+@item
+The type @code{YYSTYPE} is defined but its use is discouraged: rather
+you should refer to the parser's encapsulated type
+@code{yy::parser::semantic_type}.
+@item
+Non POD (Plain Old Data) types cannot be used. C++ forbids any
+instance of classes with constructors in unions: only @emph{pointers}
+to such objects are allowed.
+@end itemize
+
+Because objects have to be stored via pointers, memory is not
+reclaimed automatically: using the @code{%destructor} directive is the
+only means to avoid leaks. @xref{Destructor Decl, , Freeing Discarded
+Symbols}.
+
+
+@node C++ Location Values
+@subsection C++ Location Values
+@c - %locations
+@c - class Position
+@c - class Location
+@c - %define filename_type "const symbol::Symbol"
+
+When the directive @code{%locations} is used, the C++ parser supports
+location tracking, see @ref{Locations, , Locations Overview}. Two
+auxiliary classes define a @code{position}, a single point in a file,
+and a @code{location}, a range composed of a pair of
+@code{position}s (possibly spanning several files).
+
+@deftypemethod {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 @samp{@var{type}*} using @samp{%define
+filename_type "@var{type}"}.
+@end deftypemethod
+
+@deftypemethod {position} {unsigned int} line
+The line, starting at 1.
+@end deftypemethod
+
+@deftypemethod {position} {unsigned int} lines (int @var{height} = 1)
+Advance by @var{height} lines, resetting the column number.
+@end deftypemethod
+
+@deftypemethod {position} {unsigned int} column
+The column, starting at 0.
+@end deftypemethod
+
+@deftypemethod {position} {unsigned int} columns (int @var{width} = 1)
+Advance by @var{width} columns, without changing the line number.
+@end deftypemethod
+
+@deftypemethod {position} {position&} operator+= (position& @var{pos}, int @var{width})
+@deftypemethodx {position} {position} operator+ (const position& @var{pos}, int @var{width})
+@deftypemethodx {position} {position&} operator-= (const position& @var{pos}, int @var{width})
+@deftypemethodx {position} {position} operator- (position& @var{pos}, int @var{width})
+Various forms of syntactic sugar for @code{columns}.
+@end deftypemethod
+
+@deftypemethod {position} {position} operator<< (std::ostream @var{o}, const position& @var{p})
+Report @var{p} on @var{o} like this:
+@samp{@var{file}:@var{line}.@var{column}}, or
+@samp{@var{line}.@var{column}} if @var{file} is null.
+@end deftypemethod
+
+@deftypemethod {location} {position} begin
+@deftypemethodx {location} {position} end
+The first, inclusive, position of the range, and the first beyond.
+@end deftypemethod
+
+@deftypemethod {location} {unsigned int} columns (int @var{width} = 1)
+@deftypemethodx {location} {unsigned int} lines (int @var{height} = 1)
+Advance the @code{end} position.
+@end deftypemethod
+
+@deftypemethod {location} {location} operator+ (const location& @var{begin}, const location& @var{end})
+@deftypemethodx {location} {location} operator+ (const location& @var{begin}, int @var{width})
+@deftypemethodx {location} {location} operator+= (const location& @var{loc}, int @var{width})
+Various forms of syntactic sugar.
+@end deftypemethod
+
+@deftypemethod {location} {void} step ()
+Move @code{begin} onto @code{end}.
+@end deftypemethod
+
+
+@node C++ Parser Interface
+@subsection C++ Parser Interface
+@c - define parser_class_name
+@c - Ctor
+@c - parse, error, set_debug_level, debug_level, set_debug_stream,
+@c debug_stream.
+@c - Reporting errors
The output files @file{@var{output}.hh} and @file{@var{output}.cc}
declare and define the parser class in the namespace @code{yy}. The
it describes an additional member of the parser class, and an
additional argument for its constructor.
-@defcv {Type} {parser} {semantic_value_type}
-@defcvx {Type} {parser} {location_value_type}
-The types for semantics value and locations.
-@end defcv
+@defcv {Type} {parser} {semantic_value_type}
+@defcvx {Type} {parser} {location_value_type}
+The types for semantics value and locations.
+@end defcv
+
+@deftypemethod {parser} {} parser (@var{type1} @var{arg1}, ...)
+Build a new parser object. There are no arguments by default, unless
+@samp{%parse-param @{@var{type1} @var{arg1}@}} was used.
+@end deftypemethod
+
+@deftypemethod {parser} {int} parse ()
+Run the syntactic analysis, and return 0 on success, 1 otherwise.
+@end deftypemethod
+
+@deftypemethod {parser} {std::ostream&} debug_stream ()
+@deftypemethodx {parser} {void} set_debug_stream (std::ostream& @var{o})
+Get or set the stream used for tracing the parsing. It defaults to
+@code{std::cerr}.
+@end deftypemethod
+
+@deftypemethod {parser} {debug_level_type} debug_level ()
+@deftypemethodx {parser} {void} set_debug_level (debug_level @var{l})
+Get or set the tracing level. Currently its value is either 0, no trace,
+or nonzero, full tracing.
+@end deftypemethod
+
+@deftypemethod {parser} {void} error (const location_type& @var{l}, const std::string& @var{m})
+The definition for this member function must be supplied by the user:
+the parser uses it to report a parser error occurring at @var{l},
+described by @var{m}.
+@end deftypemethod
+
+
+@node C++ Scanner Interface
+@subsection C++ Scanner Interface
+@c - prefix for yylex.
+@c - Pure interface to yylex
+@c - %lex-param
+
+The parser invokes the scanner by calling @code{yylex}. Contrary to C
+parsers, C++ parsers are always pure: there is no point in using the
+@samp{%define api.pure} directive. Therefore the interface is as follows.
+
+@deftypemethod {parser} {int} yylex (semantic_value_type& @var{yylval}, location_type& @var{yylloc}, @var{type1} @var{arg1}, ...)
+Return the next token. Its type is the return value, its semantic
+value and location being @var{yylval} and @var{yylloc}. Invocations of
+@samp{%lex-param @{@var{type1} @var{arg1}@}} yield additional arguments.
+@end deftypemethod
+
+
+@node A Complete C++ Example
+@subsection 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 @dfn{../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
+@end menu
+
+@node Calc++ --- C++ Calculator
+@subsubsection 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
+@code{one} and @code{two}, is exchanged with the parser. An example
+of valid input follows.
+
+@example
+three := 3
+seven := one + two * three
+seven * seven
+@end example
+
+@node Calc++ Parsing Driver
+@subsubsection Calc++ Parsing Driver
+@c - An env
+@c - A place to store error messages
+@c - A place for the result
+
+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
+@dfn{parsing driver} class.
+
+The declaration of this driver class, @file{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.
+
+@comment file: calc++-driver.hh
+@example
+#ifndef CALCXX_DRIVER_HH
+# define CALCXX_DRIVER_HH
+# include <string>
+# include <map>
+# include "calc++-parser.hh"
+@end example
+
+
+@noindent
+Then comes the declaration of the scanning function. Flex expects
+the signature of @code{yylex} to be defined in the macro
+@code{YY_DECL}, and the C++ parser expects it to be declared. We can
+factor both as follows.
+
+@comment file: calc++-driver.hh
+@example
+// 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;
+@end example
+
+@noindent
+The @code{calcxx_driver} class is then declared with its most obvious
+members.
+
+@comment file: calc++-driver.hh
+@example
+// 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;
+@end example
+
+@noindent
+To encapsulate the coordination with the Flex scanner, it is useful to
+have two members function to open and close the scanning phase.
+
+@comment file: calc++-driver.hh
+@example
+ // Handling the scanner.
+ void scan_begin ();
+ void scan_end ();
+ bool trace_scanning;
+@end example
+
+@noindent
+Similarly for the parser itself.
+
+@comment file: calc++-driver.hh
+@example
+ // Run the parser. Return 0 on success.
+ int parse (const std::string& f);
+ std::string file;
+ bool trace_parsing;
+@end example
+
+@noindent
+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.
+
+@comment file: calc++-driver.hh
+@example
+ // Error handling.
+ void error (const yy::location& l, const std::string& m);
+ void error (const std::string& m);
+@};
+#endif // ! CALCXX_DRIVER_HH
+@end example
+
+The implementation of the driver is straightforward. The @code{parse}
+member function deserves some attention. The @code{error} functions
+are simple stubs, they should actually register the located error
+messages and set error state.
+
+@comment file: calc++-driver.cc
+@example
+#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;
+@}
+@end example
+
+@node Calc++ Parser
+@subsubsection Calc++ Parser
+
+The parser definition file @file{calc++-parser.yy} starts by asking for
+the C++ deterministic parser skeleton, the creation of the parser header
+file, and specifies the name of the parser class.
+Because the C++ skeleton changed several times, it is safer to require
+the version you designed the grammar for.
+
+@comment file: calc++-parser.yy
+@example
+%skeleton "lalr1.cc" /* -*- C++ -*- */
+%require "@value{VERSION}"
+%defines
+%define parser_class_name "calcxx_parser"
+@end example
+
+@noindent
+@findex %code requires
+Then come the declarations/inclusions needed to define the
+@code{%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.
+@xref{Decl Summary, ,%code}.
+
+@comment file: calc++-parser.yy
+@example
+%code requires @{
+# include <string>
+class calcxx_driver;
+@}
+@end example
+
+@noindent
+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.
+
+@comment file: calc++-parser.yy
+@example
+// The parsing context.
+%parse-param @{ calcxx_driver& driver @}
+%lex-param @{ calcxx_driver& driver @}
+@end example
+
+@noindent
+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.
+
+@comment file: calc++-parser.yy
+@example
+%locations
+%initial-action
+@{
+ // Initialize the initial location.
+ @@$.begin.filename = @@$.end.filename = &driver.file;
+@};
+@end example
+
+@noindent
+Use the two following directives to enable parser tracing and verbose
+error messages.
+
+@comment file: calc++-parser.yy
+@example
+%define parse.trace
+%define parse.error verbose
+@end example
+
+@noindent
+Semantic values cannot use ``real'' objects, but only pointers to
+them.
+
+@comment file: calc++-parser.yy
+@example
+// Symbols.
+%union
+@{
+ int ival;
+ std::string *sval;
+@};
+@end example
+
+@noindent
+@findex %code
+The code between @samp{%code @{} and @samp{@}} is output in the
+@file{*.cc} file; it needs detailed knowledge about the driver.
+
+@comment file: calc++-parser.yy
+@example
+%code @{
+# include "calc++-driver.hh"
+@}
+@end example
+
+
+@noindent
+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 names are provided for each symbol.
+To avoid name clashes in the generated files (@pxref{Calc++ Scanner}),
+prefix tokens with @code{TOK_} (@pxref{Decl Summary,, api.tokens.prefix}).
+
+@comment file: calc++-parser.yy
+@example
+%define api.tokens.prefix "TOK_"
+%token END 0 "end of file"
+%token ASSIGN ":="
+%token <sval> IDENTIFIER "identifier"
+%token <ival> NUMBER "number"
+%type <ival> exp
+@end example
+
+@noindent
+To enable memory deallocation during error recovery, use
+@code{%destructor}.
-@deftypemethod {parser} {} parser (@var{type1} @var{arg1}, ...)
-Build a new parser object. There are no arguments by default, unless
-@samp{%parse-param @{@var{type1} @var{arg1}@}} was used.
-@end deftypemethod
+@c FIXME: Document %printer, and mention that it takes a braced-code operand.
+@comment file: calc++-parser.yy
+@example
+%printer @{ debug_stream () << *$$; @} "identifier"
+%destructor @{ delete $$; @} "identifier"
-@deftypemethod {parser} {int} parse ()
-Run the syntactic analysis, and return 0 on success, 1 otherwise.
-@end deftypemethod
+%printer @{ debug_stream () << $$; @} <ival>
+@end example
-@deftypemethod {parser} {std::ostream&} debug_stream ()
-@deftypemethodx {parser} {void} set_debug_stream (std::ostream& @var{o})
-Get or set the stream used for tracing the parsing. It defaults to
-@code{std::cerr}.
-@end deftypemethod
+@noindent
+The grammar itself is straightforward.
-@deftypemethod {parser} {debug_level_type} debug_level ()
-@deftypemethodx {parser} {void} set_debug_level (debug_level @var{l})
-Get or set the tracing level. Currently its value is either 0, no trace,
-or nonzero, full tracing.
-@end deftypemethod
+@comment file: calc++-parser.yy
+@example
+%%
+%start unit;
+unit: assignments exp @{ driver.result = $2; @};
-@deftypemethod {parser} {void} error (const location_type& @var{l}, const std::string& @var{m})
-The definition for this member function must be supplied by the user:
-the parser uses it to report a parser error occurring at @var{l},
-described by @var{m}.
-@end deftypemethod
+assignments:
+ assignments assignment @{@}
+| /* Nothing. */ @{@};
+assignment:
+ "identifier" ":=" exp
+ @{ driver.variables[*$1] = $3; delete $1; @};
-@node C++ Scanner Interface
-@subsection C++ Scanner Interface
-@c - prefix for yylex.
-@c - Pure interface to yylex
-@c - %lex-param
+%left '+' '-';
+%left '*' '/';
+exp:
+ exp '+' exp @{ $$ = $1 + $3; @}
+| exp '-' exp @{ $$ = $1 - $3; @}
+| exp '*' exp @{ $$ = $1 * $3; @}
+| exp '/' exp @{ $$ = $1 / $3; @}
+| '(' exp ')' @{ $$ = $2; @}
+| "identifier" @{ $$ = driver.variables[*$1]; delete $1; @}
+| "number" @{ $$ = $1; @};
+%%
+@end example
-The parser invokes the scanner by calling @code{yylex}. Contrary to C
-parsers, C++ parsers are always pure: there is no point in using the
-@code{%pure-parser} directive. Therefore the interface is as follows.
+@noindent
+Finally the @code{error} member function registers the errors to the
+driver.
-@deftypemethod {parser} {int} yylex (semantic_value_type& @var{yylval}, location_type& @var{yylloc}, @var{type1} @var{arg1}, ...)
-Return the next token. Its type is the return value, its semantic
-value and location being @var{yylval} and @var{yylloc}. Invocations of
-@samp{%lex-param @{@var{type1} @var{arg1}@}} yield additional arguments.
-@end deftypemethod
+@comment file: calc++-parser.yy
+@example
+void
+yy::calcxx_parser::error (const yy::calcxx_parser::location_type& l,
+ const std::string& m)
+@{
+ driver.error (l, m);
+@}
+@end example
+@node Calc++ Scanner
+@subsubsection Calc++ Scanner
-@node A Complete C++ Example
-@section A Complete C++ Example
+The Flex scanner first includes the driver declaration, then the
+parser's to get the set of defined tokens.
-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 @dfn{../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.
+@comment file: calc++-scanner.ll
+@example
+%@{ /* -*- C++ -*- */
+# include <cstdlib>
+# include <cerrno>
+# include <climits>
+# include <string>
+# include "calc++-driver.hh"
+# include "calc++-parser.hh"
-@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
-@end menu
+/* 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
-@node Calc++ --- C++ Calculator
-@subsection Calc++ --- C++ Calculator
+/* By default yylex returns an int; we use token_type.
+ The default yyterminate implementation returns 0, which is
+ not of token_type. */
+#define yyterminate() return TOKEN(END)
+%@}
+@end example
-Of course the grammar is dedicated to arithmetics, a single
-expression, possibly preceded by variable assignments. An
-environment containing possibly predefined variables such as
-@code{one} and @code{two}, is exchanged with the parser. An example
-of valid input follows.
+@noindent
+Because there is no @code{#include}-like feature we don't need
+@code{yywrap}, we don't need @code{unput} either, and we parse an
+actual file, this is not an interactive session with the user.
+Finally we enable the scanner tracing features.
+@comment file: calc++-scanner.ll
@example
-three := 3
-seven := one + two * three
-seven * seven
+%option noyywrap nounput batch debug
@end example
-@node Calc++ Parsing Driver
-@subsection Calc++ Parsing Driver
-@c - An env
-@c - A place to store error messages
-@c - A place for the result
+@noindent
+Abbreviations allow for more readable rules.
-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
-@dfn{parsing driver} class.
+@comment file: calc++-scanner.ll
+@example
+id [a-zA-Z][a-zA-Z_0-9]*
+int [0-9]+
+blank [ \t]
+@end example
-The declaration of this driver class, @file{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.
+@noindent
+The following paragraph suffices to track locations accurately. Each
+time @code{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.
-@comment file: calc++-driver.hh
+@comment file: calc++-scanner.ll
@example
-#ifndef CALCXX_DRIVER_HH
-# define CALCXX_DRIVER_HH
-# include <string>
-# include <map>
-# include "calc++-parser.hh"
+%@{
+# define YY_USER_ACTION yylloc->columns (yyleng);
+%@}
+%%
+%@{
+ yylloc->step ();
+%@}
+@{blank@}+ yylloc->step ();
+[\n]+ yylloc->lines (yyleng); yylloc->step ();
@end example
-
@noindent
-Then comes the declaration of the scanning function. Flex expects
-the signature of @code{yylex} to be defined in the macro
-@code{YY_DECL}, and the C++ parser expects it to be declared. We can
-factor both as follows.
+The rules are simple. The driver is used to report errors. It is
+convenient to use a macro to shorten
+@code{yy::calcxx_parser::token::TOK_@var{Name}} into
+@code{TOKEN(@var{Name})}; note the token prefix, @code{TOK_}.
-@comment file: calc++-driver.hh
+@comment file: calc++-scanner.ll
@example
-// 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;
+%@{
+# define TOKEN(Name) \
+ yy::calcxx_parser::token::TOK_ ## Name
+%@}
+ /* 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");
+%%
@end example
@noindent
-The @code{calcxx_driver} class is then declared with its most obvious
-members.
+Finally, because the scanner related driver's member function depend
+on the scanner's data, it is simpler to implement them in this file.
-@comment file: calc++-driver.hh
+@comment file: calc++-scanner.ll
@example
-// Conducting the whole scanning and parsing of Calc++.
-class calcxx_driver
+void
+calcxx_driver::scan_begin ()
@{
-public:
- calcxx_driver ();
- virtual ~calcxx_driver ();
+ 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);
+ @}
+@}
- std::map<std::string, int> variables;
+void
+calcxx_driver::scan_end ()
+@{
+ fclose (yyin);
+@}
+@end example
- int result;
+@node Calc++ Top Level
+@subsubsection Calc++ Top Level
+
+The top level file, @file{calc++.cc}, poses no problem.
+
+@comment file: calc++.cc
+@example
+#include <iostream>
+#include "calc++-driver.hh"
+
+int
+main (int argc, char *argv[])
+@{
+ int res = 0;
+ 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;
+ else
+ res = 1;
+ return res;
+@}
@end example
-@noindent
-To encapsulate the coordination with the Flex scanner, it is useful to
-have two members function to open and close the scanning phase.
+@node Java Parsers
+@section 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
+@end menu
+
+@node Java Bison Interface
+@subsection Java Bison Interface
+@c - %language "Java"
+
+(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 @code{%language "Java"}
+directive or the @option{-L java}/@option{--language=java} option.
+
+@c FIXME: Documented bug.
+When generating a Java parser, @code{bison @var{basename}.y} will create
+a single Java source file named @file{@var{basename}.java}. Using an
+input file without a @file{.y} suffix is currently broken. The basename
+of the output file can be changed by the @code{%file-prefix} directive
+or the @option{-p}/@option{--name-prefix} option. The entire output file
+name can be changed by the @code{%output} directive or the
+@option{-o}/@option{--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 @code{%pure-parser}
+and @samp{%define api.pure} directives does not do anything when used in
+Java.
+
+Push parsers are currently unsupported in Java and @code{%define
+api.push-pull} have no effect.
+
+@acronym{GLR} parsers are currently unsupported in Java. Do not use the
+@code{glr-parser} directive.
+
+No header file can be generated for Java parsers. Do not use the
+@code{%defines} directive or the @option{-d}/@option{--defines} options.
+
+@c FIXME: Possible code change.
+Currently, support for tracing is always compiled
+in. Thus the @samp{%define parse.trace} and @samp{%token-table}
+directives and the
+@option{-t}/@option{--debug} and @option{-k}/@option{--token-table}
+options have no effect. This may change in the future to eliminate
+unused code in the generated parser, so use @samp{%define parse.trace}
+explicitly
+if needed. Also, in the future the
+@code{%token-table} directive might enable a public interface to
+access the token names and codes.
+
+Getting a ``code too large'' error from the Java compiler means the code
+hit the 64KB bytecode per method limination of the Java class file.
+Try reducing the amount of code in actions and static initializers;
+otherwise, report a bug so that the parser skeleton will be improved.
+
+
+@node Java Semantic Values
+@subsection Java Semantic Values
+@c - No %union, specify type in %type/%token.
+@c - YYSTYPE
+@c - Printer and destructor
+
+There is no @code{%union} directive in Java parsers. Instead, the
+semantic values' types (class names) should be specified in the
+@code{%type} or @code{%token} directive:
-@comment file: calc++-driver.hh
@example
- // Handling the scanner.
- void scan_begin ();
- void scan_end ();
- bool trace_scanning;
+%type <Expression> expr assignment_expr term factor
+%type <Integer> number
@end example
-@noindent
-Similarly for the parser itself.
+By default, the semantic stack is declared to have @code{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 @samp{%define stype}
+directive. For example, after the following declaration:
-@comment file: calc++-driver.hh
@example
- // Run the parser. Return 0 on success.
- int parse (const std::string& f);
- std::string file;
- bool trace_parsing;
+%define stype "ASTNode"
@end example
@noindent
-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.
+any @code{%type} or @code{%token} specifying a semantic type which
+is not a subclass of ASTNode, will cause a compile-time error.
-@comment file: calc++-driver.hh
-@example
- // Error handling.
- void error (const yy::location& l, const std::string& m);
- void error (const std::string& m);
-@};
-#endif // ! CALCXX_DRIVER_HH
-@end example
+@c FIXME: Documented bug.
+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.
-The implementation of the driver is straightforward. The @code{parse}
-member function deserves some attention. The @code{error} functions
-are simple stubs, they should actually register the located error
-messages and set error state.
+Java parsers do not support @code{%destructor}, since the language
+adopts garbage collection. The parser will try to hold references
+to semantic values for as little time as needed.
-@comment file: calc++-driver.cc
-@example
-#include "calc++-driver.hh"
-#include "calc++-parser.hh"
+Java parsers do not support @code{%printer}, as @code{toString()}
+can be used to print the semantic values. This however may change
+(in a backwards-compatible way) in future versions of Bison.
-calcxx_driver::calcxx_driver ()
- : trace_scanning (false), trace_parsing (false)
-@{
- variables["one"] = 1;
- variables["two"] = 2;
-@}
-calcxx_driver::~calcxx_driver ()
-@{
-@}
+@node Java Location Values
+@subsection Java Location Values
+@c - %locations
+@c - class Position
+@c - class Location
-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;
-@}
+When the directive @code{%locations} is used, the Java parser
+supports location tracking, see @ref{Locations, , Locations Overview}.
+An auxiliary user-defined class defines a @dfn{position}, a single point
+in a file; Bison itself defines a class representing a @dfn{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 @code{Location} by default, and may also be renamed using
+@samp{%define location_type "@var{class-name}"}.
-void
-calcxx_driver::error (const yy::location& l, const std::string& m)
-@{
- std::cerr << l << ": " << m << std::endl;
-@}
+The location class treats the position as a completely opaque value.
+By default, the class name is @code{Position}, but this can be changed
+with @samp{%define position_type "@var{class-name}"}. This class must
+be supplied by the user.
-void
-calcxx_driver::error (const std::string& m)
-@{
- std::cerr << m << std::endl;
-@}
-@end example
-@node Calc++ Parser
-@subsection Calc++ Parser
+@deftypeivar {Location} {Position} begin
+@deftypeivarx {Location} {Position} end
+The first, inclusive, position of the range, and the first beyond.
+@end deftypeivar
-The parser definition file @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.
+@deftypeop {Constructor} {Location} {} Location (Position @var{loc})
+Create a @code{Location} denoting an empty range located at a given point.
+@end deftypeop
-@comment file: calc++-parser.yy
-@example
-%language "C++" /* -*- C++ -*- */
-%require "@value{VERSION}"
-%defines
-%define parser_class_name "calcxx_parser"
-@end example
+@deftypeop {Constructor} {Location} {} Location (Position @var{begin}, Position @var{end})
+Create a @code{Location} from the endpoints of the range.
+@end deftypeop
-@noindent
-@findex %code requires
-Then come the declarations/inclusions needed to define the
-@code{%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.
-@xref{Table of Symbols, ,%code}.
+@deftypemethod {Location} {String} toString ()
+Prints the range represented by the location. For this to work
+properly, the position class should override the @code{equals} and
+@code{toString} methods appropriately.
+@end deftypemethod
-@comment file: calc++-parser.yy
-@example
-%code requires @{
-# include <string>
-class calcxx_driver;
-@}
-@end example
-@noindent
-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.
+@node Java Parser Interface
+@subsection Java Parser Interface
+@c - define parser_class_name
+@c - Ctor
+@c - parse, error, set_debug_level, debug_level, set_debug_stream,
+@c debug_stream.
+@c - Reporting errors
-@comment file: calc++-parser.yy
-@example
-// The parsing context.
-%parse-param @{ calcxx_driver& driver @}
-%lex-param @{ calcxx_driver& driver @}
-@end example
+The name of the generated parser class defaults to @code{YYParser}. The
+@code{YY} prefix may be changed using the @code{%name-prefix} directive
+or the @option{-p}/@option{--name-prefix} option. Alternatively, use
+@samp{%define parser_class_name "@var{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
+@samp{%define public} will change to public visibility. Remember that,
+according to the Java language specification, the name of the @file{.java}
+file should match the name of the class in this case. Similarly, you can
+use @code{abstract}, @code{final} and @code{strictfp} with the
+@code{%define} declaration to add other modifiers to the parser class.
+A single @samp{%define annotations "@var{annotations}"} directive can
+be used to add any number of annotations to the parser class.
+
+The Java package name of the parser class can be specified using the
+@samp{%define package} directive. The superclass and the implemented
+interfaces of the parser class can be specified with the @code{%define
+extends} and @samp{%define implements} directives.
+
+The parser class defines an inner class, @code{Location}, that is used
+for location tracking (see @ref{Java Location Values}), and a inner
+interface, @code{Lexer} (see @ref{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 @code{yy} or
+@code{YY} prefix to avoid clashes with user code.
+
+The parser class can be extended using the @code{%parse-param}
+directive. Each occurrence of the directive will add a @code{protected
+final} field to the parser class, and an argument to its constructor,
+which initialize them automatically.
+
+@deftypeop {Constructor} {YYParser} {} YYParser (@var{lex_param}, @dots{}, @var{parse_param}, @dots{})
+Build a new parser object with embedded @code{%code lexer}. There are
+no parameters, unless @code{%parse-param}s and/or @code{%lex-param}s are
+used.
+
+Use @code{%code init} for code added to the start of the constructor
+body. This is especially useful to initialize superclasses. Use
+@samp{%define init_throws} to specify any uncatch exceptions.
+@end deftypeop
+
+@deftypeop {Constructor} {YYParser} {} YYParser (Lexer @var{lexer}, @var{parse_param}, @dots{})
+Build a new parser object using the specified scanner. There are no
+additional parameters unless @code{%parse-param}s are used.
+
+If the scanner is defined by @code{%code lexer}, this constructor is
+declared @code{protected} and is called automatically with a scanner
+created with the correct @code{%lex-param}s.
+
+Use @code{%code init} for code added to the start of the constructor
+body. This is especially useful to initialize superclasses. Use
+@samp{%define init_throws} to specify any uncatch exceptions.
+@end deftypeop
+
+@deftypemethod {YYParser} {boolean} parse ()
+Run the syntactic analysis, and return @code{true} on success,
+@code{false} otherwise.
+@end deftypemethod
-@noindent
-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.
+@deftypemethod {YYParser} {boolean} getErrorVerbose ()
+@deftypemethodx {YYParser} {void} setErrorVerbose (boolean @var{verbose})
+Get or set the option to produce verbose error messages. These are only
+available with @samp{%define parse.error verbose}, which also turns on
+verbose error messages.
+@end deftypemethod
-@comment file: calc++-parser.yy
-@example
-%locations
-%initial-action
-@{
- // Initialize the initial location.
- @@$.begin.filename = @@$.end.filename = &driver.file;
-@};
-@end example
+@deftypemethod {YYParser} {void} yyerror (String @var{msg})
+@deftypemethodx {YYParser} {void} yyerror (Position @var{pos}, String @var{msg})
+@deftypemethodx {YYParser} {void} yyerror (Location @var{loc}, String @var{msg})
+Print an error message using the @code{yyerror} method of the scanner
+instance in use. The @code{Location} and @code{Position} parameters are
+available only if location tracking is active.
+@end deftypemethod
-@noindent
-Use the two following directives to enable parser tracing and verbose
-error messages.
+@deftypemethod {YYParser} {boolean} recovering ()
+During the syntactic analysis, return @code{true} if recovering
+from a syntax error.
+@xref{Error Recovery}.
+@end deftypemethod
-@comment file: calc++-parser.yy
-@example
-%debug
-%error-verbose
-@end example
+@deftypemethod {YYParser} {java.io.PrintStream} getDebugStream ()
+@deftypemethodx {YYParser} {void} setDebugStream (java.io.printStream @var{o})
+Get or set the stream used for tracing the parsing. It defaults to
+@code{System.err}.
+@end deftypemethod
-@noindent
-Semantic values cannot use ``real'' objects, but only pointers to
-them.
+@deftypemethod {YYParser} {int} getDebugLevel ()
+@deftypemethodx {YYParser} {void} setDebugLevel (int @var{l})
+Get or set the tracing level. Currently its value is either 0, no trace,
+or nonzero, full tracing.
+@end deftypemethod
-@comment file: calc++-parser.yy
-@example
-// Symbols.
-%union
-@{
- int ival;
- std::string *sval;
-@};
-@end example
+@deftypecv {Constant} {YYParser} {String} {bisonVersion}
+@deftypecvx {Constant} {YYParser} {String} {bisonSkeleton}
+Identify the Bison version and skeleton used to generate this parser.
+@end deftypecv
-@noindent
-@findex %code
-The code between @samp{%code @{} and @samp{@}} is output in the
-@file{*.cc} file; it needs detailed knowledge about the driver.
-@comment file: calc++-parser.yy
-@example
-%code @{
-# include "calc++-driver.hh"
-@}
-@end example
+@node Java Scanner Interface
+@subsection Java Scanner Interface
+@c - %code lexer
+@c - %lex-param
+@c - Lexer interface
+
+There are two possible ways to interface a Bison-generated Java parser
+with a scanner: the scanner may be defined by @code{%code lexer}, or
+defined elsewhere. In either case, the scanner has to implement the
+@code{Lexer} inner interface of the parser class. This interface also
+contain constants for all user-defined token names and the predefined
+@code{EOF} token.
+
+In the first case, the body of the scanner class is placed in
+@code{%code lexer} blocks. If you want to pass parameters from the
+parser constructor to the scanner constructor, specify them with
+@code{%lex-param}; they are passed before @code{%parse-param}s to the
+constructor.
+
+In the second case, the scanner has to implement the @code{Lexer} interface,
+which is defined within the parser class (e.g., @code{YYParser.Lexer}).
+The constructor of the parser object will then accept an object
+implementing the interface; @code{%lex-param} is not used in this
+case.
+
+In both cases, the scanner has to implement the following methods.
+
+@deftypemethod {Lexer} {void} yyerror (Location @var{loc}, String @var{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 @samp{%define location_type "@var{class-name}".}
+@end deftypemethod
+@deftypemethod {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.
-@noindent
-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 @code{TOKEN_} to
-avoid name clashes.
+Use @samp{%define lex_throws} to specify any uncaught exceptions.
+Default is @code{java.io.IOException}.
+@end deftypemethod
-@comment file: calc++-parser.yy
-@example
-%token END 0 "end of file"
-%token ASSIGN ":="
-%token <sval> IDENTIFIER "identifier"
-%token <ival> NUMBER "number"
-%type <ival> exp "expression"
-@end example
+@deftypemethod {Lexer} {Position} getStartPos ()
+@deftypemethodx {Lexer} {Position} getEndPos ()
+Return respectively the first position of the last token that
+@code{yylex} returned, and the first position beyond it. These
+methods are not needed unless location tracking is active.
-@noindent
-To enable memory deallocation during error recovery, use
-@code{%destructor}.
+The return type can be changed using @samp{%define position_type
+"@var{class-name}".}
+@end deftypemethod
-@c FIXME: Document %printer, and mention that it takes a braced-code operand.
-@comment file: calc++-parser.yy
-@example
-%printer @{ debug_stream () << *$$; @} "identifier"
-%destructor @{ delete $$; @} "identifier"
+@deftypemethod {Lexer} {Object} getLVal ()
+Return the semantical value of the last token that yylex returned.
-%printer @{ debug_stream () << $$; @} "number" "expression"
-@end example
+The return type can be changed using @samp{%define stype
+"@var{class-name}".}
+@end deftypemethod
-@noindent
-The grammar itself is straightforward.
-@comment file: calc++-parser.yy
-@example
-%%
-%start unit;
-unit: assignments exp @{ driver.result = $2; @};
+@node Java Action Features
+@subsection 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 @samp{%define throws} to specify any uncaught exceptions from parser
+actions, and initial actions specified by @code{%initial-action}.
+
+@defvar $@var{n}
+The semantic value for the @var{n}th component of the current rule.
+This may not be assigned to.
+@xref{Java Semantic Values}.
+@end defvar
+
+@defvar $<@var{typealt}>@var{n}
+Like @code{$@var{n}} but specifies a alternative type @var{typealt}.
+@xref{Java Semantic Values}.
+@end defvar
+
+@defvar $$
+The semantic value for the grouping made by the current rule. As a
+value, this is in the base type (@code{Object} or as specified by
+@samp{%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.
+@xref{Java Semantic Values}.
+@end defvar
+
+@defvar $<@var{typealt}>$
+Same as @code{$$} since Java always allow assigning to the base type.
+Perhaps we should use this and @code{$<>$} for the value and @code{$$}
+for setting the value but there is currently no easy way to distinguish
+these constructs.
+@xref{Java Semantic Values}.
+@end defvar
+
+@defvar @@@var{n}
+The location information of the @var{n}th component of the current rule.
+This may not be assigned to.
+@xref{Java Location Values}.
+@end defvar
+
+@defvar @@$
+The location information of the grouping made by the current rule.
+@xref{Java Location Values}.
+@end defvar
+
+@deffn {Statement} {return YYABORT;}
+Return immediately from the parser, indicating failure.
+@xref{Java Parser Interface}.
+@end deffn
-assignments: assignments assignment @{@}
- | /* Nothing. */ @{@};
+@deffn {Statement} {return YYACCEPT;}
+Return immediately from the parser, indicating success.
+@xref{Java Parser Interface}.
+@end deffn
-assignment:
- "identifier" ":=" exp
- @{ driver.variables[*$1] = $3; delete $1; @};
+@deffn {Statement} {return YYERROR;}
+Start error recovery without printing an error message.
+@xref{Error Recovery}.
+@end deffn
-%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; @};
-%%
-@end example
+@deffn {Statement} {return YYFAIL;}
+Print an error message and start error recovery.
+@xref{Error Recovery}.
+@end deffn
-@noindent
-Finally the @code{error} member function registers the errors to the
-driver.
+@deftypefn {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.
+@xref{Error Recovery}.
+@end deftypefn
-@comment file: calc++-parser.yy
-@example
-void
-yy::calcxx_parser::error (const yy::calcxx_parser::location_type& l,
- const std::string& m)
-@{
- driver.error (l, m);
-@}
-@end example
+@deftypefn {Function} {void} yyerror (String @var{msg})
+@deftypefnx {Function} {void} yyerror (Position @var{loc}, String @var{msg})
+@deftypefnx {Function} {void} yyerror (Location @var{loc}, String @var{msg})
+Print an error message using the @code{yyerror} method of the scanner
+instance in use. The @code{Location} and @code{Position} parameters are
+available only if location tracking is active.
+@end deftypefn
-@node Calc++ Scanner
-@subsection Calc++ Scanner
-The Flex scanner first includes the driver declaration, then the
-parser's to get the set of defined tokens.
+@node Java Differences
+@subsection 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.
+
+@itemize
+@item
+Java lacks a preprocessor, so the @code{YYERROR}, @code{YYACCEPT},
+@code{YYABORT} symbols (@pxref{Table of Symbols}) cannot obviously be
+macros. Instead, they should be preceded by @code{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 @pxref{Java Action Features}.
+
+Note that of these three symbols, only @code{YYACCEPT} and
+@code{YYABORT} will cause a return from the @code{yyparse}
+method@footnote{Java parsers include the actions in a separate
+method than @code{yyparse} in order to have an intuitive syntax that
+corresponds to these C macros.}.
+
+@item
+Java lacks unions, so @code{%union} has no effect. Instead, semantic
+values have a common base type: @code{Object} or as specified by
+@samp{%define stype}. Angle backets on @code{%token}, @code{type},
+@code{$@var{n}} and @code{$$} specify subtypes rather than fields of
+an union. The type of @code{$$}, even with angle brackets, is the base
+type since Java casts are not allow on the left-hand side of assignments.
+Also, @code{$@var{n}} and @code{@@@var{n}} are not allowed on the
+left-hand side of assignments. See @pxref{Java Semantic Values} and
+@pxref{Java Action Features}.
+
+@item
+The prolog declarations have a different meaning than in C/C++ code.
+@table @asis
+@item @code{%code imports}
+blocks are placed at the beginning of the Java source code. They may
+include copyright notices. For a @code{package} declarations, it is
+suggested to use @samp{%define package} instead.
+
+@item unqualified @code{%code}
+blocks are placed inside the parser class.
+
+@item @code{%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 @pxref{Java Scanner
+Interface}).
+@end table
+
+Other @code{%code} blocks are not supported in Java parsers.
+In particular, @code{%@{ @dots{} %@}} 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 @emph{outside}
+the parser class.
+@end itemize
+
+
+@node Java Declarations Summary
+@subsection Java Declarations Summary
+
+This summary only include declarations specific to Java or have special
+meaning when used in a Java parser.
+
+@deffn {Directive} {%language "Java"}
+Generate a Java class for the parser.
+@end deffn
+
+@deffn {Directive} %lex-param @{@var{type} @var{name}@}
+A parameter for the lexer class defined by @code{%code lexer}
+@emph{only}, added as parameters to the lexer constructor and the parser
+constructor that @emph{creates} a lexer. Default is none.
+@xref{Java Scanner Interface}.
+@end deffn
+
+@deffn {Directive} %name-prefix "@var{prefix}"
+The prefix of the parser class name @code{@var{prefix}Parser} if
+@samp{%define parser_class_name} is not used. Default is @code{YY}.
+@xref{Java Bison Interface}.
+@end deffn
+
+@deffn {Directive} %parse-param @{@var{type} @var{name}@}
+A parameter for the parser class added as parameters to constructor(s)
+and as fields initialized by the constructor(s). Default is none.
+@xref{Java Parser Interface}.
+@end deffn
+
+@deffn {Directive} %token <@var{type}> @var{token} @dots{}
+Declare tokens. Note that the angle brackets enclose a Java @emph{type}.
+@xref{Java Semantic Values}.
+@end deffn
+
+@deffn {Directive} %type <@var{type}> @var{nonterminal} @dots{}
+Declare the type of nonterminals. Note that the angle brackets enclose
+a Java @emph{type}.
+@xref{Java Semantic Values}.
+@end deffn
+
+@deffn {Directive} %code @{ @var{code} @dots{} @}
+Code appended to the inside of the parser class.
+@xref{Java Differences}.
+@end deffn
+
+@deffn {Directive} {%code imports} @{ @var{code} @dots{} @}
+Code inserted just after the @code{package} declaration.
+@xref{Java Differences}.
+@end deffn
+
+@deffn {Directive} {%code init} @{ @var{code} @dots{} @}
+Code inserted at the beginning of the parser constructor body.
+@xref{Java Parser Interface}.
+@end deffn
+
+@deffn {Directive} {%code lexer} @{ @var{code} @dots{} @}
+Code added to the body of a inner lexer class within the parser class.
+@xref{Java Scanner Interface}.
+@end deffn
-@comment file: calc++-scanner.ll
-@example
-%@{ /* -*- C++ -*- */
-# include <cstdlib>
-# include <errno.h>
-# include <limits.h>
-# include <string>
-# include "calc++-driver.hh"
-# include "calc++-parser.hh"
+@deffn {Directive} %% @var{code} @dots{}
+Code (after the second @code{%%}) appended to the end of the file,
+@emph{outside} the parser class.
+@xref{Java Differences}.
+@end deffn
-/* 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
+@deffn {Directive} %@{ @var{code} @dots{} %@}
+Not supported. Use @code{%code imports} instead.
+@xref{Java Differences}.
+@end deffn
-/* 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
-%@}
-@end example
+@deffn {Directive} {%define abstract}
+Whether the parser class is declared @code{abstract}. Default is false.
+@xref{Java Bison Interface}.
+@end deffn
-@noindent
-Because there is no @code{#include}-like feature we don't need
-@code{yywrap}, we don't need @code{unput} either, and we parse an
-actual file, this is not an interactive session with the user.
-Finally we enable the scanner tracing features.
+@deffn {Directive} {%define annotations} "@var{annotations}"
+The Java annotations for the parser class. Default is none.
+@xref{Java Bison Interface}.
+@end deffn
-@comment file: calc++-scanner.ll
-@example
-%option noyywrap nounput batch debug
-@end example
+@deffn {Directive} {%define extends} "@var{superclass}"
+The superclass of the parser class. Default is none.
+@xref{Java Bison Interface}.
+@end deffn
-@noindent
-Abbreviations allow for more readable rules.
+@deffn {Directive} {%define final}
+Whether the parser class is declared @code{final}. Default is false.
+@xref{Java Bison Interface}.
+@end deffn
-@comment file: calc++-scanner.ll
-@example
-id [a-zA-Z][a-zA-Z_0-9]*
-int [0-9]+
-blank [ \t]
-@end example
+@deffn {Directive} {%define implements} "@var{interfaces}"
+The implemented interfaces of the parser class, a comma-separated list.
+Default is none.
+@xref{Java Bison Interface}.
+@end deffn
-@noindent
-The following paragraph suffices to track locations accurately. Each
-time @code{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.
+@deffn {Directive} {%define init_throws} "@var{exceptions}"
+The exceptions thrown by @code{%code init} from the parser class
+constructor. Default is none.
+@xref{Java Parser Interface}.
+@end deffn
-@comment file: calc++-scanner.ll
-@example
-%@{
-# define YY_USER_ACTION yylloc->columns (yyleng);
-%@}
-%%
-%@{
- yylloc->step ();
-%@}
-@{blank@}+ yylloc->step ();
-[\n]+ yylloc->lines (yyleng); yylloc->step ();
-@end example
+@deffn {Directive} {%define lex_throws} "@var{exceptions}"
+The exceptions thrown by the @code{yylex} method of the lexer, a
+comma-separated list. Default is @code{java.io.IOException}.
+@xref{Java Scanner Interface}.
+@end deffn
-@noindent
-The rules are simple, just note the use of the driver to report errors.
-It is convenient to use a typedef to shorten
-@code{yy::calcxx_parser::token::identifier} into
-@code{token::identifier} for instance.
+@deffn {Directive} {%define location_type} "@var{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 @command{bison}. Default is @code{Location}.
+@xref{Java Location Values}.
+@end deffn
-@comment file: calc++-scanner.ll
-@example
-%@{
- 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");
-%%
-@end example
+@deffn {Directive} {%define package} "@var{package}"
+The package to put the parser class in. Default is none.
+@xref{Java Bison Interface}.
+@end deffn
-@noindent
-Finally, because the scanner related driver's member function depend
-on the scanner's data, it is simpler to implement them in this file.
+@deffn {Directive} {%define parser_class_name} "@var{name}"
+The name of the parser class. Default is @code{YYParser} or
+@code{@var{name-prefix}Parser}.
+@xref{Java Bison Interface}.
+@end deffn
-@comment file: calc++-scanner.ll
-@example
-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);
- @}
-@}
+@deffn {Directive} {%define position_type} "@var{class}"
+The name of the class used for positions. This class must be supplied by
+the user. Default is @code{Position}.
+@xref{Java Location Values}.
+@end deffn
-void
-calcxx_driver::scan_end ()
-@{
- fclose (yyin);
-@}
-@end example
+@deffn {Directive} {%define public}
+Whether the parser class is declared @code{public}. Default is false.
+@xref{Java Bison Interface}.
+@end deffn
-@node Calc++ Top Level
-@subsection Calc++ Top Level
+@deffn {Directive} {%define stype} "@var{class}"
+The base type of semantic values. Default is @code{Object}.
+@xref{Java Semantic Values}.
+@end deffn
-The top level file, @file{calc++.cc}, poses no problem.
+@deffn {Directive} {%define strictfp}
+Whether the parser class is declared @code{strictfp}. Default is false.
+@xref{Java Bison Interface}.
+@end deffn
-@comment file: calc++.cc
-@example
-#include <iostream>
-#include "calc++-driver.hh"
+@deffn {Directive} {%define throws} "@var{exceptions}"
+The exceptions thrown by user-supplied parser actions and
+@code{%initial-action}, a comma-separated list. Default is none.
+@xref{Java Parser Interface}.
+@end deffn
-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;
-@}
-@end example
@c ================================================= FAQ
* I can't build Bison:: Troubleshooting
* Where can I find help?:: Troubleshouting
* Bug Reports:: Troublereporting
-* Other Languages:: Parsers in Java and others
+* More Languages:: Parsers in C++, Java, and so on
* Beta Testing:: Experimenting development versions
* Mailing Lists:: Meeting other Bison users
@end menu
@display
My parser includes support for an @samp{#include}-like feature, in
which case I run @code{yyparse} from @code{yyparse}. This fails
-although I did specify I needed a @code{%pure-parser}.
+although I did specify @samp{%define api.pure}.
@end display
These problems typically come not from Bison itself, but from
Send bug reports to @email{bug-bison@@gnu.org}.
-@node Other Languages
-@section Other Languages
+@node More Languages
+@section More Languages
@display
-Will Bison ever have C++ support? How about Java or @var{insert your
+Will Bison ever have C++ and Java support? How about @var{insert your
favorite language here}?
@end display
-C++ support is there now, and is documented. We'd love to add other
+C++ and Java support is there now, and is documented. We'd love to add other
languages; contributions are welcome.
@node Beta Testing
@end deffn
@deffn {Directive} %code @{@var{code}@}
-@findex %code
-This is the unqualified form of the @code{%code} directive.
-It inserts @var{code} verbatim at the default location in the output.
-That default location is determined by the selected target language and/or
-parser skeleton.
-
-@cindex Prologue
-For the current C/C++ skeletons, the default location is the parser source code
-file after the usual contents of the parser header file.
-Thus, @code{%code} replaces the traditional Yacc prologue,
-@code{%@{@var{code}%@}}, for most purposes.
-For a detailed discussion, see @ref{Prologue Alternatives}.
-
-@comment 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.)
-@end deffn
-
-@deffn {Directive} %code @var{qualifier} @{@var{code}@}
-This is the qualified form of the @code{%code} directive.
-If you need to specify location-sensitive verbatim @var{code} that does not
-belong at the default location selected by the unqualified @code{%code} form,
-use this form instead.
-
-@var{qualifier} identifies the purpose of @var{code} and thus the location(s)
-where Bison should generate it.
-Not all values of @var{qualifier} are available for all target languages:
-
-@itemize @bullet
-@findex %code requires
-@item requires
-
-@itemize @bullet
-@item Language(s): C, C++
-
-@item Purpose: This is the best place to write dependency code required for
-@code{YYSTYPE} and @code{YYLTYPE}.
-In other words, it's the best place to define types referenced in @code{%union}
-directives, and it's the best place to override Bison's default @code{YYSTYPE}
-and @code{YYLTYPE} definitions.
-
-@item Location(s): The parser header file and the parser source code file
-before the Bison-generated @code{YYSTYPE} and @code{YYLTYPE} definitions.
-@end itemize
-
-@item provides
-@findex %code provides
-
-@itemize @bullet
-@item Language(s): C, C++
-
-@item Purpose: This is the best place to write additional definitions and
-declarations that should be provided to other modules.
-
-@item Location(s): The parser header file and the parser source code file after
-the Bison-generated @code{YYSTYPE}, @code{YYLTYPE}, and token definitions.
-@end itemize
-
-@item top
-@findex %code top
-
-@itemize @bullet
-@item Language(s): C, C++
-
-@item Purpose: The unqualified @code{%code} or @code{%code requires} should
-usually be more appropriate than @code{%code top}.
-However, occasionally it is necessary to insert code much nearer the top of the
-parser source code file.
-For example:
-
-@smallexample
-%code top @{
- #define _GNU_SOURCE
- #include <stdio.h>
-@}
-@end smallexample
-
-@item Location(s): Near the top of the parser source code file.
-@end itemize
-@ignore
-@item imports
-@findex %code imports
-
-@itemize @bullet
-@item Language(s): Java
-
-@item Purpose: This is the best place to write Java import directives.
-
-@item Location(s): The parser Java file after any Java package directive and
-before any class definitions.
-@end itemize
-@end ignore
-@end itemize
-
-(Like all the Yacc prologue alternatives, this directive is experimental.
-More user feedback will help to determine whether it should become a permanent
-feature.)
-
-@cindex Prologue
-For a detailed discussion of how to use @code{%code} in place of the
-traditional Yacc prologue for C/C++, see @ref{Prologue Alternatives}.
-@end deffn
-
-@deffn {Directive} %debug
-Equip the parser for debugging. @xref{Decl Summary}.
+@deffnx {Directive} %code @var{qualifier} @{@var{code}@}
+Insert @var{code} verbatim into output parser source.
+@xref{Decl Summary,,%code}.
@end deffn
@deffn {Directive} %debug
@end deffn
@end ifset
+@deffn {Directive} %define @var{define-variable}
+@deffnx {Directive} %define @var{define-variable} @var{value}
+@deffnx {Directive} %define @var{define-variable} "@var{value}"
+Define a variable to adjust Bison's behavior.
+@xref{Decl Summary,,%define}.
+@end deffn
+
@deffn {Directive} %defines
Bison declaration to create a header file meant for the scanner.
@xref{Decl Summary}.
@end deffn
@deffn {Directive} %error-verbose
-Bison declaration to request verbose, specific error message strings
-when @code{yyerror} is called.
+An obsolete directive standing for @samp{%define parse.error verbose}.
@end deffn
@deffn {Directive} %file-prefix "@var{prefix}"
@end deffn
@deffn {Directive} %left
-Bison declaration to assign left associativity to token(s).
+Bison declaration to assign precedence and left associativity to token(s).
@xref{Precedence Decl, ,Operator Precedence}.
@end deffn
@end deffn
@deffn {Directive} %nonassoc
-Bison declaration to assign nonassociativity to token(s).
+Bison declaration to assign precedence and nonassociativity to token(s).
@xref{Precedence Decl, ,Operator Precedence}.
@end deffn
@xref{Contextual Precedence, ,Context-Dependent Precedence}.
@end deffn
+@deffn {Directive} %precedence
+Bison declaration to assign precedence to token(s), but no associativity
+@xref{Precedence Decl, ,Operator Precedence}.
+@end deffn
+
@deffn {Directive} %pure-parser
-Bison declaration to request a pure (reentrant) parser.
-@xref{Pure Decl, ,A Pure (Reentrant) Parser}.
+Deprecated version of @samp{%define api.pure} (@pxref{Decl Summary, ,%define}),
+for which Bison is more careful to warn about unreasonable usage.
@end deffn
@deffn {Directive} %require "@var{version}"
@end deffn
@deffn {Directive} %right
-Bison declaration to assign right associativity to token(s).
+Bison declaration to assign precedence and right associativity to token(s).
@xref{Precedence Decl, ,Operator Precedence}.
@end deffn
making @code{yyparse} return 1 immediately. The error reporting
function @code{yyerror} is not called. @xref{Parser Function, ,The
Parser Function @code{yyparse}}.
+
+For Java parsers, this functionality is invoked using @code{return YYABORT;}
+instead.
@end deffn
@deffn {Macro} YYACCEPT
Macro to pretend that a complete utterance of the language has been
read, by making @code{yyparse} return 0 immediately.
@xref{Parser Function, ,The Parser Function @code{yyparse}}.
+
+For Java parsers, this functionality is invoked using @code{return YYACCEPT;}
+instead.
@end deffn
@deffn {Macro} YYBACKUP
@code{yyerror} and then perform normal error recovery if possible
(@pxref{Error Recovery}), or (if recovery is impossible) make
@code{yyparse} return 1. @xref{Error Recovery}.
+
+For Java parsers, this functionality is invoked using @code{return YYERROR;}
+instead.
@end deffn
@deffn {Function} yyerror
User-supplied function to be called by @code{yyparse} on error.
-@xref{Error Reporting, ,The Error
-Reporting Function @code{yyerror}}.
+@xref{Error Reporting, ,The Error Reporting Function @code{yyerror}}.
@end deffn
@deffn {Macro} YYERROR_VERBOSE
-An obsolete macro that you define with @code{#define} in the prologue
-to request verbose, specific error message strings
-when @code{yyerror} is called. It doesn't matter what definition you
-use for @code{YYERROR_VERBOSE}, just whether you define it. Using
-@code{%error-verbose} is preferred.
+An obsolete macro used in the @file{yacc.c} skeleton, that you define
+with @code{#define} in the prologue to request verbose, specific error
+message strings when @code{yyerror} is called. It doesn't matter what
+definition you use for @code{YYERROR_VERBOSE}, just whether you define
+it. Using @samp{%define parse.error verbose} is preferred
+(@pxref{Error Reporting, ,The Error Reporting Function @code{yyerror}}).
@end deffn
@deffn {Macro} YYINITDEPTH
@deffn {Variable} yynerrs
Global variable which Bison increments each time it reports a syntax error.
-(In a pure parser, it is a local variable within @code{yyparse}.)
+(In a pure parser, it is a local variable within @code{yyparse}. In a
+pure push parser, it is a member of yypstate.)
@xref{Error Reporting, ,The Error Reporting Function @code{yyerror}}.
@end deffn
parsing. @xref{Parser Function, ,The Parser Function @code{yyparse}}.
@end deffn
+@deffn {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.
+@xref{Parser Delete Function, ,The Parser Delete Function
+@code{yypstate_delete}}.
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+@end deffn
+
+@deffn {Function} yypstate_new
+The function to create a parser instance, produced by Bison in push mode;
+call this function to create a new parser.
+@xref{Parser Create Function, ,The Parser Create Function
+@code{yypstate_new}}.
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+@end deffn
+
+@deffn {Function} yypull_parse
+The parser function produced by Bison in push mode; call this function to
+parse the rest of the input stream.
+@xref{Pull Parser Function, ,The Pull Parser Function
+@code{yypull_parse}}.
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+@end deffn
+
+@deffn {Function} yypush_parse
+The parser function produced by Bison in push mode; call this function to
+parse a single token. @xref{Push Parser Function, ,The Push Parser Function
+@code{yypush_parse}}.
+(The current push parsing interface is experimental and may evolve.
+More user feedback will help to stabilize it.)
+@end deffn
+
@deffn {Macro} YYPARSE_PARAM
An obsolete macro for specifying the name of a parameter that
@code{yyparse} should accept. The use of this macro is deprecated, and
@end deffn
@deffn {Macro} YYSTACK_USE_ALLOCA
-Macro used to control the use of @code{alloca} when the C
-@acronym{LALR}(1) parser needs to extend its stacks. If defined to 0,
+Macro used to control the use of @code{alloca} when the
+deterministic parser in C needs to extend its stacks. If defined to 0,
the parser will use @code{malloc} to extend its stacks. If defined to
1, the parser will use @code{alloca}. Values other than 0 and 1 are
reserved for future Bison extensions. If not defined,
@cindex glossary
@table @asis
+@item Accepting State
+A state whose only action is the accept action.
+The accepting state is thus a consistent state.
+@xref{Understanding,,}.
+
@item Backus-Naur Form (@acronym{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.
@xref{Language and Grammar, ,Languages and Context-Free Grammars}.
+@item Consistent State
+A state containing only one possible action.
+@xref{Decl Summary,,lr.default-reductions}.
+
@item 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
permitted. @xref{Language and Grammar, ,Languages and Context-Free
Grammars}.
+@item Default Reduction
+The reduction that a parser should perform if the current parser state
+contains no other action for the lookahead token.
+In permitted parser states, Bison declares the reduction with the
+largest lookahead set to be the default reduction and removes that
+lookahead set.
+@xref{Decl Summary,,lr.default-reductions}.
+
@item Dynamic allocation
Allocation of memory that occurs during execution, rather than at
compile time or on entry to a function.
@item Generalized @acronym{LR} (@acronym{GLR})
A parsing algorithm that can handle all context-free grammars, including those
-that are not @acronym{LALR}(1). It resolves situations that Bison's
-usual @acronym{LALR}(1)
+that are not @acronym{LR}(1). It resolves situations that Bison's
+deterministic parsing
algorithm cannot by effectively splitting off multiple parsers, trying all
possible parsers, and discarding those that fail in the light of additional
right context. @xref{Generalized LR Parsing, ,Generalized
for example, `expression' or `declaration' in C@.
@xref{Language and Grammar, ,Languages and Context-Free Grammars}.
+@item @acronym{IELR}(1)
+A minimal @acronym{LR}(1) parser table generation algorithm.
+That is, given any context-free grammar, @acronym{IELR}(1) generates
+parser tables with the full language recognition power of canonical
+@acronym{LR}(1) but with nearly the same number of parser states as
+@acronym{LALR}(1).
+This reduction in parser states is often an order of magnitude.
+More importantly, because canonical @acronym{LR}(1)'s extra parser
+states may contain duplicate conflicts in the case of
+non-@acronym{LR}(1) grammars, the number of conflicts for
+@acronym{IELR}(1) is often an order of magnitude less as well.
+This can significantly reduce the complexity of developing of a grammar.
+@xref{Decl Summary,,lr.type}.
+
@item Infix operator
An arithmetic operator that is placed between the operands on which it
performs some operation.
@item @acronym{LALR}(1)
The class of context-free grammars that Bison (like most other parser
-generators) can handle; a subset of @acronym{LR}(1). @xref{Mystery
-Conflicts, ,Mysterious Reduce/Reduce Conflicts}.
+generators) can handle by default; a subset of @acronym{LR}(1).
+@xref{Mystery Conflicts, ,Mysterious Reduce/Reduce Conflicts}.
@item @acronym{LR}(1)
The class of context-free grammars in which at most one token of
@node Copying This Manual
@appendix Copying This Manual
-
-@menu
-* GNU Free Documentation License:: License for copying this manual.
-@end menu
-
@include fdl.texi
@node Index
@bye
+@c Local Variables:
+@c fill-column: 76
+@c End:
+
@c LocalWords: texinfo setfilename settitle setchapternewpage finalout
@c LocalWords: ifinfo smallbook shorttitlepage titlepage GPL FIXME iftex
@c LocalWords: akim fn cp syncodeindex vr tp synindex dircategory direntry
@c LocalWords: ifset vskip pt filll insertcopying sp ISBN Etienne Suvasa
@c LocalWords: ifnottex yyparse detailmenu GLR RPN Calc var Decls Rpcalc
-@c LocalWords: rpcalc Lexer Gen Comp Expr ltcalc mfcalc Decl Symtab yylex
+@c LocalWords: rpcalc Lexer Expr ltcalc mfcalc yylex
@c LocalWords: yyerror pxref LR yylval cindex dfn LALR samp gpl BNF xref
@c LocalWords: const int paren ifnotinfo AC noindent emph expr stmt findex
@c LocalWords: glr YYSTYPE TYPENAME prog dprec printf decl init stmtMerge
@c LocalWords: infile ypp yxx outfile itemx tex leaderfill
@c LocalWords: hbox hss hfill tt ly yyin fopen fclose ofirst gcc ll
@c LocalWords: nbar yytext fst snd osplit ntwo strdup AST
-@c LocalWords: YYSTACK DVI fdl printindex
+@c LocalWords: YYSTACK DVI fdl printindex IELR
projects / bison.git / blobdiff