This is bison.info, produced by makeinfo version 4.13 from /Users/akim/src/gnu/bison-2.5/doc/bison.texi. This manual (27 July 2012) is for GNU Bison (version 2.6.1-dirty), the GNU parser generator. Copyright (C) 1988-1993, 1995, 1998-2012 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being "A GNU Manual," and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled "GNU Free Documentation License." (a) The FSF's Back-Cover Text is: "You have the freedom to copy and modify this GNU manual. Buying copies from the FSF supports it in developing GNU and promoting software freedom." INFO-DIR-SECTION Software development START-INFO-DIR-ENTRY * bison: (bison). GNU parser generator (Yacc replacement). END-INFO-DIR-ENTRY  File: bison.info, Node: Memory Management, Prev: Generalized LR Parsing, Up: Algorithm 5.10 Memory Management, and How to Avoid Memory Exhaustion ========================================================== The Bison parser stack can run out of memory if too many tokens are shifted and not reduced. When this happens, the parser function `yyparse' calls `yyerror' and then returns 2. Because Bison parsers have growing stacks, hitting the upper limit usually results from using a right recursion instead of a left recursion, see *note Recursive Rules: Recursion. By defining the macro `YYMAXDEPTH', you can control how deep the parser stack can become before memory is exhausted. Define the macro with a value that is an integer. This value is the maximum number of tokens that can be shifted (and not reduced) before overflow. The stack space allowed is not necessarily allocated. If you specify a large value for `YYMAXDEPTH', the parser normally allocates a small stack at first, and then makes it bigger by stages as needed. This increasing allocation happens automatically and silently. Therefore, you do not need to make `YYMAXDEPTH' painfully small merely to save space for ordinary inputs that do not need much stack. However, do not allow `YYMAXDEPTH' to be a value so large that arithmetic overflow could occur when calculating the size of the stack space. Also, do not allow `YYMAXDEPTH' to be less than `YYINITDEPTH'. The default value of `YYMAXDEPTH', if you do not define it, is 10000. You can control how much stack is allocated initially by defining the macro `YYINITDEPTH' to a positive integer. For the deterministic parser in C, this value must be a compile-time constant unless you are assuming C99 or some other target language or compiler that allows variable-length arrays. The default is 200. Do not allow `YYINITDEPTH' to be greater than `YYMAXDEPTH'. Because of semantic differences between C and C++, the deterministic parsers in C produced by Bison cannot grow when compiled by C++ compilers. In this precise case (compiling a C parser as C++) you are suggested to grow `YYINITDEPTH'. The Bison maintainers hope to fix this deficiency in a future release.  File: bison.info, Node: Error Recovery, Next: Context Dependency, Prev: Algorithm, Up: Top 6 Error Recovery **************** It is not usually acceptable to have a program terminate on a syntax error. For example, a compiler should recover sufficiently to parse the rest of the input file and check it for errors; a calculator should accept another expression. In a simple interactive command parser where each input is one line, it may be sufficient to allow `yyparse' to return 1 on error and have the caller ignore the rest of the input line when that happens (and then call `yyparse' again). But this is inadequate for a compiler, because it forgets all the syntactic context leading up to the error. A syntax error deep within a function in the compiler input should not cause the compiler to treat the following line like the beginning of a source file. You can define how to recover from a syntax error by writing rules to recognize the special token `error'. This is a terminal symbol that is always defined (you need not declare it) and reserved for error handling. The Bison parser generates an `error' token whenever a syntax error happens; if you have provided a rule to recognize this token in the current context, the parse can continue. For example: stmts: /* empty string */ | stmts '\n' | stmts exp '\n' | stmts error '\n' The fourth rule in this example says that an error followed by a newline makes a valid addition to any `stmts'. What happens if a syntax error occurs in the middle of an `exp'? The error recovery rule, interpreted strictly, applies to the precise sequence of a `stmts', an `error' and a newline. If an error occurs in the middle of an `exp', there will probably be some additional tokens and subexpressions on the stack after the last `stmts', and there will be tokens to read before the next newline. So the rule is not applicable in the ordinary way. But Bison can force the situation to fit the rule, by discarding part of the semantic context and part of the input. First it discards states and objects from the stack until it gets back to a state in which the `error' token is acceptable. (This means that the subexpressions already parsed are discarded, back to the last complete `stmts'.) At this point the `error' token can be shifted. Then, if the old lookahead token is not acceptable to be shifted next, the parser reads tokens and discards them until it finds a token which is acceptable. In this example, Bison reads and discards input until the next newline so that the fourth rule can apply. Note that discarded symbols are possible sources of memory leaks, see *note Freeing Discarded Symbols: Destructor Decl, for a means to reclaim this memory. The choice of error rules in the grammar is a choice of strategies for error recovery. A simple and useful strategy is simply to skip the rest of the current input line or current statement if an error is detected: stmt: error ';' /* On error, skip until ';' is read. */ It is also useful to recover to the matching close-delimiter of an opening-delimiter that has already been parsed. Otherwise the close-delimiter will probably appear to be unmatched, and generate another, spurious error message: primary: '(' expr ')' | '(' error ')' ... ; Error recovery strategies are necessarily guesses. When they guess wrong, one syntax error often leads to another. In the above example, the error recovery rule guesses that an error is due to bad input within one `stmt'. Suppose that instead a spurious semicolon is inserted in the middle of a valid `stmt'. After the error recovery rule recovers from the first error, another syntax error will be found straightaway, since the text following the spurious semicolon is also an invalid `stmt'. To prevent an outpouring of error messages, the parser will output no error message for another syntax error that happens shortly after the first; only after three consecutive input tokens have been successfully shifted will error messages resume. Note that rules which accept the `error' token may have actions, just as any other rules can. You can make error messages resume immediately by using the macro `yyerrok' in an action. If you do this in the error rule's action, no error messages will be suppressed. This macro requires no arguments; `yyerrok;' is a valid C statement. The previous lookahead token is reanalyzed immediately after an error. If this is unacceptable, then the macro `yyclearin' may be used to clear this token. Write the statement `yyclearin;' in the error rule's action. *Note Special Features for Use in Actions: Action Features. For example, suppose that on a syntax error, an error handling routine is called that advances the input stream to some point where parsing should once again commence. The next symbol returned by the lexical scanner is probably correct. The previous lookahead token ought to be discarded with `yyclearin;'. The expression `YYRECOVERING ()' yields 1 when the parser is recovering from a syntax error, and 0 otherwise. Syntax error diagnostics are suppressed while recovering from a syntax error.  File: bison.info, Node: Context Dependency, Next: Debugging, Prev: Error Recovery, Up: Top 7 Handling Context Dependencies ******************************* The Bison paradigm is to parse tokens first, then group them into larger syntactic units. In many languages, the meaning of a token is affected by its context. Although this violates the Bison paradigm, certain techniques (known as "kludges") may enable you to write Bison parsers for such languages. * Menu: * Semantic Tokens:: Token parsing can depend on the semantic context. * Lexical Tie-ins:: Token parsing can depend on the syntactic context. * Tie-in Recovery:: Lexical tie-ins have implications for how error recovery rules must be written. (Actually, "kludge" means any technique that gets its job done but is neither clean nor robust.)  File: bison.info, Node: Semantic Tokens, Next: Lexical Tie-ins, Up: Context Dependency 7.1 Semantic Info in Token Types ================================ The C language has a context dependency: the way an identifier is used depends on what its current meaning is. For example, consider this: foo (x); This looks like a function call statement, but if `foo' is a typedef name, then this is actually a declaration of `x'. How can a Bison parser for C decide how to parse this input? The method used in GNU C is to have two different token types, `IDENTIFIER' and `TYPENAME'. When `yylex' finds an identifier, it looks up the current declaration of the identifier in order to decide which token type to return: `TYPENAME' if the identifier is declared as a typedef, `IDENTIFIER' otherwise. The grammar rules can then express the context dependency by the choice of token type to recognize. `IDENTIFIER' is accepted as an expression, but `TYPENAME' is not. `TYPENAME' can start a declaration, but `IDENTIFIER' cannot. In contexts where the meaning of the identifier is _not_ significant, such as in declarations that can shadow a typedef name, either `TYPENAME' or `IDENTIFIER' is accepted--there is one rule for each of the two token types. This technique is simple to use if the decision of which kinds of identifiers to allow is made at a place close to where the identifier is parsed. But in C this is not always so: C allows a declaration to redeclare a typedef name provided an explicit type has been specified earlier: typedef int foo, bar; int baz (void) { static bar (bar); /* redeclare `bar' as static variable */ extern foo foo (foo); /* redeclare `foo' as function */ return foo (bar); } Unfortunately, the name being declared is separated from the declaration construct itself by a complicated syntactic structure--the "declarator". As a result, part of the Bison parser for C needs to be duplicated, with all the nonterminal names changed: once for parsing a declaration in which a typedef name can be redefined, and once for parsing a declaration in which that can't be done. Here is a part of the duplication, with actions omitted for brevity: initdcl: declarator maybeasm '=' init | declarator maybeasm ; notype_initdcl: notype_declarator maybeasm '=' init | notype_declarator maybeasm ; Here `initdcl' can redeclare a typedef name, but `notype_initdcl' cannot. The distinction between `declarator' and `notype_declarator' is the same sort of thing. There is some similarity between this technique and a lexical tie-in (described next), in that information which alters the lexical analysis is changed during parsing by other parts of the program. The difference is here the information is global, and is used for other purposes in the program. A true lexical tie-in has a special-purpose flag controlled by the syntactic context.  File: bison.info, Node: Lexical Tie-ins, Next: Tie-in Recovery, Prev: Semantic Tokens, Up: Context Dependency 7.2 Lexical Tie-ins =================== One way to handle context-dependency is the "lexical tie-in": a flag which is set by Bison actions, whose purpose is to alter the way tokens are parsed. For example, suppose we have a language vaguely like C, but with a special construct `hex (HEX-EXPR)'. After the keyword `hex' comes an expression in parentheses in which all integers are hexadecimal. In particular, the token `a1b' must be treated as an integer rather than as an identifier if it appears in that context. Here is how you can do it: %{ int hexflag; int yylex (void); void yyerror (char const *); %} %% ... expr: IDENTIFIER | constant | HEX '(' { hexflag = 1; } expr ')' { hexflag = 0; $$ = $4; } | expr '+' expr { $$ = make_sum ($1, $3); } ... ; constant: INTEGER | STRING ; Here we assume that `yylex' looks at the value of `hexflag'; when it is nonzero, all integers are parsed in hexadecimal, and tokens starting with letters are parsed as integers if possible. The declaration of `hexflag' shown in the prologue of the grammar file is needed to make it accessible to the actions (*note The Prologue: Prologue.). You must also write the code in `yylex' to obey the flag.  File: bison.info, Node: Tie-in Recovery, Prev: Lexical Tie-ins, Up: Context Dependency 7.3 Lexical Tie-ins and Error Recovery ====================================== Lexical tie-ins make strict demands on any error recovery rules you have. *Note Error Recovery::. The reason for this is that the purpose of an error recovery rule is to abort the parsing of one construct and resume in some larger construct. For example, in C-like languages, a typical error recovery rule is to skip tokens until the next semicolon, and then start a new statement, like this: stmt: expr ';' | IF '(' expr ')' stmt { ... } ... | error ';' { hexflag = 0; } ; If there is a syntax error in the middle of a `hex (EXPR)' construct, this error rule will apply, and then the action for the completed `hex (EXPR)' will never run. So `hexflag' would remain set for the entire rest of the input, or until the next `hex' keyword, causing identifiers to be misinterpreted as integers. To avoid this problem the error recovery rule itself clears `hexflag'. There may also be an error recovery rule that works within expressions. For example, there could be a rule which applies within parentheses and skips to the close-parenthesis: expr: ... | '(' expr ')' { $$ = $2; } | '(' error ')' ... If this rule acts within the `hex' construct, it is not going to abort that construct (since it applies to an inner level of parentheses within the construct). Therefore, it should not clear the flag: the rest of the `hex' construct should be parsed with the flag still in effect. What if there is an error recovery rule which might abort out of the `hex' construct or might not, depending on circumstances? There is no way you can write the action to determine whether a `hex' construct is being aborted or not. So if you are using a lexical tie-in, you had better make sure your error recovery rules are not of this kind. Each rule must be such that you can be sure that it always will, or always won't, have to clear the flag.  File: bison.info, Node: Debugging, Next: Invocation, Prev: Context Dependency, Up: Top 8 Debugging Your Parser *********************** Developing a parser can be a challenge, especially if you don't understand the algorithm (*note The Bison Parser Algorithm: Algorithm.). This chapter explains how to generate and read the detailed description of the automaton, and how to enable and understand the parser run-time traces. * Menu: * Understanding:: Understanding the structure of your parser. * Tracing:: Tracing the execution of your parser.  File: bison.info, Node: Understanding, Next: Tracing, Up: Debugging 8.1 Understanding Your Parser ============================= As documented elsewhere (*note The Bison Parser Algorithm: Algorithm.) Bison parsers are "shift/reduce automata". In some cases (much more frequent than one would hope), looking at this automaton is required to tune or simply fix a parser. Bison provides two different representation of it, either textually or graphically (as a DOT file). The textual file is generated when the options `--report' or `--verbose' are specified, see *note Invoking Bison: Invocation. Its name is made by removing `.tab.c' or `.c' from the parser implementation file name, and adding `.output' instead. Therefore, if the grammar file is `foo.y', then the parser implementation file is called `foo.tab.c' by default. As a consequence, the verbose output file is called `foo.output'. The following grammar file, `calc.y', will be used in the sequel: %token NUM STR %left '+' '-' %left '*' %% exp: exp '+' exp | exp '-' exp | exp '*' exp | exp '/' exp | NUM ; useless: STR; %% `bison' reports: calc.y: warning: 1 nonterminal useless in grammar calc.y: warning: 1 rule useless in grammar calc.y:11.1-7: warning: nonterminal useless in grammar: useless calc.y:11.10-12: warning: rule useless in grammar: useless: STR calc.y: conflicts: 7 shift/reduce When given `--report=state', in addition to `calc.tab.c', it creates a file `calc.output' with contents detailed below. The order of the output and the exact presentation might vary, but the interpretation is the same. The first section reports useless tokens, nonterminals and rules. Useless nonterminals and rules are removed in order to produce a smaller parser, but useless tokens are preserved, since they might be used by the scanner (note the difference between "useless" and "unused" below): Nonterminals useless in grammar useless Terminals unused in grammar STR Rules useless in grammar 6 useless: STR The next section lists states that still have conflicts. State 8 conflicts: 1 shift/reduce State 9 conflicts: 1 shift/reduce State 10 conflicts: 1 shift/reduce State 11 conflicts: 4 shift/reduce Then Bison reproduces the exact grammar it used: Grammar 0 $accept: exp $end 1 exp: exp '+' exp 2 | exp '-' exp 3 | exp '*' exp 4 | exp '/' exp 5 | NUM and reports the uses of the symbols: Terminals, with rules where they appear $end (0) 0 '*' (42) 3 '+' (43) 1 '-' (45) 2 '/' (47) 4 error (256) NUM (258) 5 STR (259) Nonterminals, with rules where they appear $accept (9) on left: 0 exp (10) on left: 1 2 3 4 5, on right: 0 1 2 3 4 Bison then proceeds onto the automaton itself, describing each state with its set of "items", also known as "pointed rules". Each item is a production rule together with a point (`.') marking the location of the input cursor. state 0 0 $accept: . exp $end NUM shift, and go to state 1 exp go to state 2 This reads as follows: "state 0 corresponds to being at the very beginning of the parsing, in the initial rule, right before the start symbol (here, `exp'). When the parser returns to this state right after having reduced a rule that produced an `exp', the control flow jumps to state 2. If there is no such transition on a nonterminal symbol, and the lookahead is a `NUM', then this token is shifted onto the parse stack, and the control flow jumps to state 1. Any other lookahead triggers a syntax error." Even though the only active rule in state 0 seems to be rule 0, the report lists `NUM' as a lookahead token because `NUM' can be at the beginning of any rule deriving an `exp'. By default Bison reports the so-called "core" or "kernel" of the item set, but if you want to see more detail you can invoke `bison' with `--report=itemset' to list the derived items as well: state 0 0 $accept: . exp $end 1 exp: . exp '+' exp 2 | . exp '-' exp 3 | . exp '*' exp 4 | . exp '/' exp 5 | . NUM NUM shift, and go to state 1 exp go to state 2 In the state 1... state 1 5 exp: NUM . $default reduce using rule 5 (exp) the rule 5, `exp: NUM;', is completed. Whatever the lookahead token (`$default'), the parser will reduce it. If it was coming from state 0, then, after this reduction it will return to state 0, and will jump to state 2 (`exp: go to state 2'). state 2 0 $accept: exp . $end 1 exp: exp . '+' exp 2 | exp . '-' exp 3 | exp . '*' exp 4 | exp . '/' exp $end shift, and go to state 3 '+' shift, and go to state 4 '-' shift, and go to state 5 '*' shift, and go to state 6 '/' shift, and go to state 7 In state 2, the automaton can only shift a symbol. For instance, because of the item `exp: exp . '+' exp', if the lookahead is `+' it is shifted onto the parse stack, and the automaton jumps to state 4, corresponding to the item `exp: exp '+' . exp'. Since there is no default action, any lookahead not listed triggers a syntax error. The state 3 is named the "final state", or the "accepting state": state 3 0 $accept: exp $end . $default accept the initial rule is completed (the start symbol and the end-of-input were read), the parsing exits successfully. The interpretation of states 4 to 7 is straightforward, and is left to the reader. state 4 1 exp: exp '+' . exp NUM shift, and go to state 1 exp go to state 8 state 5 2 exp: exp '-' . exp NUM shift, and go to state 1 exp go to state 9 state 6 3 exp: exp '*' . exp NUM shift, and go to state 1 exp go to state 10 state 7 4 exp: exp '/' . exp NUM shift, and go to state 1 exp go to state 11 As was announced in beginning of the report, `State 8 conflicts: 1 shift/reduce': state 8 1 exp: exp . '+' exp 1 | exp '+' exp . 2 | exp . '-' exp 3 | exp . '*' exp 4 | exp . '/' exp '*' shift, and go to state 6 '/' shift, and go to state 7 '/' [reduce using rule 1 (exp)] $default reduce using rule 1 (exp) Indeed, there are two actions associated to the lookahead `/': either shifting (and going to state 7), or reducing rule 1. The conflict means that either the grammar is ambiguous, or the parser lacks information to make the right decision. Indeed the grammar is ambiguous, as, since we did not specify the precedence of `/', the sentence `NUM + NUM / NUM' can be parsed as `NUM + (NUM / NUM)', which corresponds to shifting `/', or as `(NUM + NUM) / NUM', which corresponds to reducing rule 1. Because in deterministic parsing a single decision can be made, Bison arbitrarily chose to disable the reduction, see *note Shift/Reduce Conflicts: Shift/Reduce. Discarded actions are reported between square brackets. Note that all the previous states had a single possible action: either shifting the next token and going to the corresponding state, or reducing a single rule. In the other cases, i.e., when shifting _and_ reducing is possible or when _several_ reductions are possible, the lookahead is required to select the action. State 8 is one such state: if the lookahead is `*' or `/' then the action is shifting, otherwise the action is reducing rule 1. In other words, the first two items, corresponding to rule 1, are not eligible when the lookahead token is `*', since we specified that `*' has higher precedence than `+'. More generally, some items are eligible only with some set of possible lookahead tokens. When run with `--report=lookahead', Bison specifies these lookahead tokens: state 8 1 exp: exp . '+' exp 1 | exp '+' exp . [$end, '+', '-', '/'] 2 | exp . '-' exp 3 | exp . '*' exp 4 | exp . '/' exp '*' shift, and go to state 6 '/' shift, and go to state 7 '/' [reduce using rule 1 (exp)] $default reduce using rule 1 (exp) Note however that while `NUM + NUM / NUM' is ambiguous (which results in the conflicts on `/'), `NUM + NUM * NUM' is not: the conflict was solved thanks to associativity and precedence directives. If invoked with `--report=solved', Bison includes information about the solved conflicts in the report: Conflict between rule 1 and token '+' resolved as reduce (%left '+'). Conflict between rule 1 and token '-' resolved as reduce (%left '-'). Conflict between rule 1 and token '*' resolved as shift ('+' < '*'). The remaining states are similar: state 9 1 exp: exp . '+' exp 2 | exp . '-' exp 2 | exp '-' exp . 3 | exp . '*' exp 4 | exp . '/' exp '*' shift, and go to state 6 '/' shift, and go to state 7 '/' [reduce using rule 2 (exp)] $default reduce using rule 2 (exp) state 10 1 exp: exp . '+' exp 2 | exp . '-' exp 3 | exp . '*' exp 3 | exp '*' exp . 4 | exp . '/' exp '/' shift, and go to state 7 '/' [reduce using rule 3 (exp)] $default reduce using rule 3 (exp) state 11 1 exp: exp . '+' exp 2 | exp . '-' exp 3 | exp . '*' exp 4 | exp . '/' exp 4 | exp '/' exp . '+' shift, and go to state 4 '-' shift, and go to state 5 '*' shift, and go to state 6 '/' shift, and go to state 7 '+' [reduce using rule 4 (exp)] '-' [reduce using rule 4 (exp)] '*' [reduce using rule 4 (exp)] '/' [reduce using rule 4 (exp)] $default reduce using rule 4 (exp) Observe that state 11 contains conflicts not only due to the lack of precedence of `/' with respect to `+', `-', and `*', but also because the associativity of `/' is not specified.  File: bison.info, Node: Tracing, Prev: Understanding, Up: Debugging 8.2 Tracing Your Parser ======================= When a Bison grammar compiles properly but parses "incorrectly", the `yydebug' parser-trace feature helps figuring out why. * Menu: * Enabling Traces:: Activating run-time trace support * Mfcalc Traces:: Extending `mfcalc' to support traces * The YYPRINT Macro:: Obsolete interface for semantic value reports  File: bison.info, Node: Enabling Traces, Next: Mfcalc Traces, Up: Tracing 8.2.1 Enabling Traces --------------------- There are several means to enable compilation of trace facilities: the macro `YYDEBUG' Define the macro `YYDEBUG' to a nonzero value when you compile the parser. This is compliant with POSIX Yacc. You could use `-DYYDEBUG=1' as a compiler option or you could put `#define YYDEBUG 1' in the prologue of the grammar file (*note The Prologue: Prologue.). If the `%define' variable `api.prefix' is used (*note Multiple Parsers in the Same Program: Multiple Parsers.), for instance `%define api.prefix x', then if `CDEBUG' is defined, its value controls the tracing feature (enabled iff nonzero); otherwise tracing is enabled iff `YYDEBUG' is nonzero. the option `-t' (POSIX Yacc compliant) the option `--debug' (Bison extension) Use the `-t' option when you run Bison (*note Invoking Bison: Invocation.). With `%define api.prefix c', it defines `CDEBUG' to 1, otherwise it defines `YYDEBUG' to 1. the directive `%debug' Add the `%debug' directive (*note Bison Declaration Summary: Decl Summary.). This is a Bison extension, especially useful for languages that don't use a preprocessor. Unless POSIX and Yacc portability matter to you, this is the preferred solution. We suggest that you always enable the debug option so that debugging is always possible. The trace facility outputs messages with macro calls of the form `YYFPRINTF (stderr, FORMAT, ARGS)' where FORMAT and ARGS are the usual `printf' format and variadic arguments. If you define `YYDEBUG' to a nonzero value but do not define `YYFPRINTF', `' is automatically included and `YYFPRINTF' is defined to `fprintf'. Once you have compiled the program with trace facilities, the way to request a trace is to store a nonzero value in the variable `yydebug'. You can do this by making the C code do it (in `main', perhaps), or you can alter the value with a C debugger. Each step taken by the parser when `yydebug' is nonzero produces a line or two of trace information, written on `stderr'. The trace messages tell you these things: * Each time the parser calls `yylex', what kind of token was read. * Each time a token is shifted, the depth and complete contents of the state stack (*note Parser States::). * Each time a rule is reduced, which rule it is, and the complete contents of the state stack afterward. To make sense of this information, it helps to refer to the automaton description file (*note Understanding Your Parser: Understanding.). This file shows the meaning of each state in terms of positions in various rules, and also what each state will do with each possible input token. As you read the successive trace messages, you can see that the parser is functioning according to its specification in the listing file. Eventually you will arrive at the place where something undesirable happens, and you will see which parts of the grammar are to blame. The parser implementation file is a C/C++/Java program and you can use debuggers on it, but it's not easy to interpret what it is doing. The parser function is a finite-state machine interpreter, and aside from the actions it executes the same code over and over. Only the values of variables show where in the grammar it is working.  File: bison.info, Node: Mfcalc Traces, Next: The YYPRINT Macro, Prev: Enabling Traces, Up: Tracing 8.2.2 Enabling Debug Traces for `mfcalc' ---------------------------------------- The debugging information normally gives the token type of each token read, but not its semantic value. The `%printer' directive allows specify how semantic values are reported, see *note Printing Semantic Values: Printer Decl. For backward compatibility, Yacc like C parsers may also use the `YYPRINT' (*note The `YYPRINT' Macro: The YYPRINT Macro.), but its use is discouraged. As a demonstration of `%printer', consider the multi-function calculator, `mfcalc' (*note Multi-function Calc::). To enable run-time traces, and semantic value reports, insert the following directives in its prologue: /* Generate the parser description file. */ %verbose /* Enable run-time traces (yydebug). */ %define parse.trace /* Formatting semantic values. */ %printer { fprintf (yyoutput, "%s", $$->name); } VAR; %printer { fprintf (yyoutput, "%s()", $$->name); } FNCT; %printer { fprintf (yyoutput, "%g", $$); } ; The `%define' directive instructs Bison to generate run-time trace support. Then, activation of these traces is controlled at run-time by the `yydebug' variable, which is disabled by default. Because these traces will refer to the "states" of the parser, it is helpful to ask for the creation of a description of that parser; this is the purpose of (admittedly ill-named) `%verbose' directive. The set of `%printer' directives demonstrates how to format the semantic value in the traces. Note that the specification can be done either on the symbol type (e.g., `VAR' or `FNCT'), or on the type tag: since `' is the type for both `NUM' and `exp', this printer will be used for them. Here is a sample of the information provided by run-time traces. The traces are sent onto standard error. $ echo 'sin(1-1)' | ./mfcalc -p Starting parse Entering state 0 Reducing stack by rule 1 (line 34): -> $$ = nterm input () Stack now 0 Entering state 1 This first batch shows a specific feature of this grammar: the first rule (which is in line 34 of `mfcalc.y' can be reduced without even having to look for the first token. The resulting left-hand symbol (`$$') is a valueless (`()') `input' non terminal (`nterm'). Then the parser calls the scanner. Reading a token: Next token is token FNCT (sin()) Shifting token FNCT (sin()) Entering state 6 That token (`token') is a function (`FNCT') whose value is `sin' as formatted per our `%printer' specification: `sin()'. The parser stores (`Shifting') that token, and others, until it can do something about it. Reading a token: Next token is token '(' () Shifting token '(' () Entering state 14 Reading a token: Next token is token NUM (1.000000) Shifting token NUM (1.000000) Entering state 4 Reducing stack by rule 6 (line 44): $1 = token NUM (1.000000) -> $$ = nterm exp (1.000000) Stack now 0 1 6 14 Entering state 24 The previous reduction demonstrates the `%printer' directive for `': both the token `NUM' and the resulting non-terminal `exp' have `1' as value. Reading a token: Next token is token '-' () Shifting token '-' () Entering state 17 Reading a token: Next token is token NUM (1.000000) Shifting token NUM (1.000000) Entering state 4 Reducing stack by rule 6 (line 44): $1 = token NUM (1.000000) -> $$ = nterm exp (1.000000) Stack now 0 1 6 14 24 17 Entering state 26 Reading a token: Next token is token ')' () Reducing stack by rule 11 (line 49): $1 = nterm exp (1.000000) $2 = token '-' () $3 = nterm exp (1.000000) -> $$ = nterm exp (0.000000) Stack now 0 1 6 14 Entering state 24 The rule for the subtraction was just reduced. The parser is about to discover the end of the call to `sin'. Next token is token ')' () Shifting token ')' () Entering state 31 Reducing stack by rule 9 (line 47): $1 = token FNCT (sin()) $2 = token '(' () $3 = nterm exp (0.000000) $4 = token ')' () -> $$ = nterm exp (0.000000) Stack now 0 1 Entering state 11 Finally, the end-of-line allow the parser to complete the computation, and display its result. Reading a token: Next token is token '\n' () Shifting token '\n' () Entering state 22 Reducing stack by rule 4 (line 40): $1 = nterm exp (0.000000) $2 = token '\n' () => 0 -> $$ = nterm line () Stack now 0 1 Entering state 10 Reducing stack by rule 2 (line 35): $1 = nterm input () $2 = nterm line () -> $$ = nterm input () Stack now 0 Entering state 1 The parser has returned into state 1, in which it is waiting for the next expression to evaluate, or for the end-of-file token, which causes the completion of the parsing. Reading a token: Now at end of input. Shifting token $end () Entering state 2 Stack now 0 1 2 Cleanup: popping token $end () Cleanup: popping nterm input ()  File: bison.info, Node: The YYPRINT Macro, Prev: Mfcalc Traces, Up: Tracing 8.2.3 The `YYPRINT' Macro ------------------------- Before `%printer' support, semantic values could be displayed using the `YYPRINT' macro, which works only for terminal symbols and only with the `yacc.c' skeleton. -- Macro: YYPRINT (STREAM, TOKEN, VALUE); If you define `YYPRINT', it should take three arguments. The parser will pass a standard I/O stream, the numeric code for the token type, and the token value (from `yylval'). For `yacc.c' only. Obsoleted by `%printer'. Here is an example of `YYPRINT' suitable for the multi-function calculator (*note Declarations for `mfcalc': Mfcalc Declarations.): %{ static void print_token_value (FILE *, int, YYSTYPE); #define YYPRINT(File, Type, Value) \ print_token_value (File, Type, Value) %} ... %% ... %% ... static void print_token_value (FILE *file, int type, YYSTYPE value) { if (type == VAR) fprintf (file, "%s", value.tptr->name); else if (type == NUM) fprintf (file, "%d", value.val); }  File: bison.info, Node: Invocation, Next: Other Languages, Prev: Debugging, Up: Top 9 Invoking Bison **************** The usual way to invoke Bison is as follows: bison INFILE Here INFILE is the grammar file name, which usually ends in `.y'. The parser implementation file's name is made by replacing the `.y' with `.tab.c' and removing any leading directory. Thus, the `bison foo.y' file name yields `foo.tab.c', and the `bison hack/foo.y' file name yields `foo.tab.c'. It's also possible, in case you are writing C++ code instead of C in your grammar file, to name it `foo.ypp' or `foo.y++'. Then, the output files will take an extension like the given one as input (respectively `foo.tab.cpp' and `foo.tab.c++'). This feature takes effect with all options that manipulate file names like `-o' or `-d'. For example : bison -d INFILE.YXX will produce `infile.tab.cxx' and `infile.tab.hxx', and bison -d -o OUTPUT.C++ INFILE.Y will produce `output.c++' and `outfile.h++'. For compatibility with POSIX, the standard Bison distribution also contains a shell script called `yacc' that invokes Bison with the `-y' option. * Menu: * Bison Options:: All the options described in detail, in alphabetical order by short options. * Option Cross Key:: Alphabetical list of long options. * Yacc Library:: Yacc-compatible `yylex' and `main'.  File: bison.info, Node: Bison Options, Next: Option Cross Key, Up: Invocation 9.1 Bison Options ================= Bison supports both traditional single-letter options and mnemonic long option names. Long option names are indicated with `--' instead of `-'. Abbreviations for option names are allowed as long as they are unique. When a long option takes an argument, like `--file-prefix', connect the option name and the argument with `='. Here is a list of options that can be used with Bison, alphabetized by short option. It is followed by a cross key alphabetized by long option. Operations modes: `-h' `--help' Print a summary of the command-line options to Bison and exit. `-V' `--version' Print the version number of Bison and exit. `--print-localedir' Print the name of the directory containing locale-dependent data. `--print-datadir' Print the name of the directory containing skeletons and XSLT. `-y' `--yacc' Act more like the traditional Yacc command. This can cause different diagnostics to be generated, and may change behavior in other minor ways. Most importantly, imitate Yacc's output file name conventions, so that the parser implementation file is called `y.tab.c', and the other outputs are called `y.output' and `y.tab.h'. Also, if generating a deterministic parser in C, generate `#define' statements in addition to an `enum' to associate token numbers with token names. Thus, the following shell script can substitute for Yacc, and the Bison distribution contains such a script for compatibility with POSIX: #! /bin/sh bison -y "$@" The `-y'/`--yacc' option is intended for use with traditional Yacc grammars. If your grammar uses a Bison extension like `%glr-parser', Bison might not be Yacc-compatible even if this option is specified. `-W [CATEGORY]' `--warnings[=CATEGORY]' Output warnings falling in CATEGORY. CATEGORY can be one of: `midrule-values' Warn about mid-rule values that are set but not used within any of the actions of the parent rule. For example, warn about unused `$2' in: exp: '1' { $$ = 1; } '+' exp { $$ = $1 + $4; }; Also warn about mid-rule values that are used but not set. For example, warn about unset `$$' in the mid-rule action in: exp: '1' { $1 = 1; } '+' exp { $$ = $2 + $4; }; These warnings are not enabled by default since they sometimes prove to be false alarms in existing grammars employing the Yacc constructs `$0' or `$-N' (where N is some positive integer). `yacc' Incompatibilities with POSIX Yacc. `conflicts-sr' `conflicts-rr' S/R and R/R conflicts. These warnings are enabled by default. However, if the `%expect' or `%expect-rr' directive is specified, an unexpected number of conflicts is an error, and an expected number of conflicts is not reported, so `-W' and `--warning' then have no effect on the conflict report. `other' All warnings not categorized above. These warnings are enabled by default. This category is provided merely for the sake of completeness. Future releases of Bison may move warnings from this category to new, more specific categories. `all' All the warnings. `none' Turn off all the warnings. `error' Treat warnings as errors. A category can be turned off by prefixing its name with `no-'. For instance, `-Wno-yacc' will hide the warnings about POSIX Yacc incompatibilities. Tuning the parser: `-t' `--debug' In the parser implementation file, define the macro `YYDEBUG' to 1 if it is not already defined, so that the debugging facilities are compiled. *Note Tracing Your Parser: Tracing. `-D NAME[=VALUE]' `--define=NAME[=VALUE]' `-F NAME[=VALUE]' `--force-define=NAME[=VALUE]' Each of these is equivalent to `%define NAME "VALUE"' (*note %define Summary::) except that Bison processes multiple definitions for the same NAME as follows: * Bison quietly ignores all command-line definitions for NAME except the last. * If that command-line definition is specified by a `-D' or `--define', Bison reports an error for any `%define' definition for NAME. * If that command-line definition is specified by a `-F' or `--force-define' instead, Bison quietly ignores all `%define' definitions for NAME. * Otherwise, Bison reports an error if there are multiple `%define' definitions for NAME. You should avoid using `-F' and `--force-define' in your make files unless you are confident that it is safe to quietly ignore any conflicting `%define' that may be added to the grammar file. `-L LANGUAGE' `--language=LANGUAGE' Specify the programming language for the generated parser, as if `%language' was specified (*note Bison Declaration Summary: Decl Summary.). Currently supported languages include C, C++, and Java. LANGUAGE is case-insensitive. This option is experimental and its effect may be modified in future releases. `--locations' Pretend that `%locations' was specified. *Note Decl Summary::. `-p PREFIX' `--name-prefix=PREFIX' Pretend that `%name-prefix "PREFIX"' was specified (*note Decl Summary::). Obsoleted by `-Dapi.prefix=PREFIX'. *Note Multiple Parsers in the Same Program: Multiple Parsers. `-l' `--no-lines' Don't put any `#line' preprocessor commands in the parser implementation file. Ordinarily Bison puts them in the parser implementation file so that the C compiler and debuggers will associate errors with your source file, the grammar file. This option causes them to associate errors with the parser implementation file, treating it as an independent source file in its own right. `-S FILE' `--skeleton=FILE' Specify the skeleton to use, similar to `%skeleton' (*note Bison Declaration Summary: Decl Summary.). If FILE does not contain a `/', FILE is the name of a skeleton file in the Bison installation directory. If it does, FILE is an absolute file name or a file name relative to the current working directory. This is similar to how most shells resolve commands. `-k' `--token-table' Pretend that `%token-table' was specified. *Note Decl Summary::. Adjust the output: `--defines[=FILE]' Pretend that `%defines' was specified, i.e., write an extra output file containing macro definitions for the token type names defined in the grammar, as well as a few other declarations. *Note Decl Summary::. `-d' This is the same as `--defines' except `-d' does not accept a FILE argument since POSIX Yacc requires that `-d' can be bundled with other short options. `-b FILE-PREFIX' `--file-prefix=PREFIX' Pretend that `%file-prefix' was specified, i.e., specify prefix to use for all Bison output file names. *Note Decl Summary::. `-r THINGS' `--report=THINGS' Write an extra output file containing verbose description of the comma separated list of THINGS among: `state' Description of the grammar, conflicts (resolved and unresolved), and parser's automaton. `lookahead' Implies `state' and augments the description of the automaton with each rule's lookahead set. `itemset' Implies `state' and augments the description of the automaton with the full set of items for each state, instead of its core only. `--report-file=FILE' Specify the FILE for the verbose description. `-v' `--verbose' Pretend that `%verbose' was specified, i.e., write an extra output file containing verbose descriptions of the grammar and parser. *Note Decl Summary::. `-o FILE' `--output=FILE' Specify the FILE for the parser implementation file. The other output files' names are constructed from FILE as described under the `-v' and `-d' options. `-g [FILE]' `--graph[=FILE]' Output a graphical representation of the parser's automaton computed by Bison, in Graphviz (http://www.graphviz.org/) DOT (http://www.graphviz.org/doc/info/lang.html) format. `FILE' is optional. If omitted and the grammar file is `foo.y', the output file will be `foo.dot'. `-x [FILE]' `--xml[=FILE]' Output an XML report of the parser's automaton computed by Bison. `FILE' is optional. If omitted and the grammar file is `foo.y', the output file will be `foo.xml'. (The current XML schema is experimental and may evolve. More user feedback will help to stabilize it.)  File: bison.info, Node: Option Cross Key, Next: Yacc Library, Prev: Bison Options, Up: Invocation 9.2 Option Cross Key ==================== Here is a list of options, alphabetized by long option, to help you find the corresponding short option and directive. Long Option Short Option Bison Directive --------------------------------------------------------------------------------- `--debug' `-t' `%debug' `--define=NAME[=VALUE]' `-D NAME[=VALUE]' `%define NAME ["VALUE"]' `--defines[=FILE]' `-d' `%defines ["FILE"]' `--file-prefix=PREFIX' `-b PREFIX' `%file-prefix "PREFIX"' `--force-define=NAME[=VALUE]' `-F NAME[=VALUE]' `%define NAME ["VALUE"]' `--graph[=FILE]' `-g [FILE]' `--help' `-h' `--language=LANGUAGE' `-L LANGUAGE' `%language "LANGUAGE"' `--locations' `%locations' `--name-prefix=PREFIX' `-p PREFIX' `%name-prefix "PREFIX"' `--no-lines' `-l' `%no-lines' `--output=FILE' `-o FILE' `%output "FILE"' `--print-datadir' `--print-localedir' `--report-file=FILE' `--report=THINGS' `-r THINGS' `--skeleton=FILE' `-S FILE' `%skeleton "FILE"' `--token-table' `-k' `%token-table' `--verbose' `-v' `%verbose' `--version' `-V' `--warnings[=CATEGORY]' `-W [CATEGORY]' `--xml[=FILE]' `-x [FILE]' `--yacc' `-y' `%yacc'  File: bison.info, Node: Yacc Library, Prev: Option Cross Key, Up: Invocation 9.3 Yacc Library ================ The Yacc library contains default implementations of the `yyerror' and `main' functions. These default implementations are normally not useful, but POSIX requires them. To use the Yacc library, link your program with the `-ly' option. Note that Bison's implementation of the Yacc library is distributed under the terms of the GNU General Public License (*note Copying::). If you use the Yacc library's `yyerror' function, you should declare `yyerror' as follows: int yyerror (char const *); Bison ignores the `int' value returned by this `yyerror'. If you use the Yacc library's `main' function, your `yyparse' function should have the following type signature: int yyparse (void);  File: bison.info, Node: Other Languages, Next: FAQ, Prev: Invocation, Up: Top 10 Parsers Written In Other Languages ************************************* * Menu: * C++ Parsers:: The interface to generate C++ parser classes * Java Parsers:: The interface to generate Java parser classes  File: bison.info, Node: C++ Parsers, Next: Java Parsers, Up: Other Languages 10.1 C++ Parsers ================ * Menu: * C++ Bison Interface:: Asking for C++ parser generation * C++ Semantic Values:: %union vs. C++ * C++ Location Values:: The position and location classes * C++ Parser Interface:: Instantiating and running the parser * C++ Scanner Interface:: Exchanges between yylex and parse * A Complete C++ Example:: Demonstrating their use  File: bison.info, Node: C++ Bison Interface, Next: C++ Semantic Values, Up: C++ Parsers 10.1.1 C++ Bison Interface -------------------------- The C++ deterministic parser is selected using the skeleton directive, `%skeleton "lalr1.cc"', or the synonymous command-line option `--skeleton=lalr1.cc'. *Note Decl Summary::. When run, `bison' will create several entities in the `yy' namespace. Use the `%define namespace' directive to change the namespace name, see *note namespace: %define Summary. The various classes are generated in the following files: `position.hh' `location.hh' The definition of the classes `position' and `location', used for location tracking. *Note C++ Location Values::. `stack.hh' An auxiliary class `stack' used by the parser. `FILE.hh' `FILE.cc' (Assuming the extension of the grammar file was `.yy'.) The declaration and implementation of the C++ parser class. The basename and extension of these two files follow the same rules as with regular C parsers (*note Invocation::). The header is _mandatory_; you must either pass `-d'/`--defines' to `bison', or use the `%defines' directive. All these files are documented using Doxygen; run `doxygen' for a complete and accurate documentation.  File: bison.info, Node: C++ Semantic Values, Next: C++ Location Values, Prev: C++ Bison Interface, Up: C++ Parsers 10.1.2 C++ Semantic Values -------------------------- The `%union' directive works as for C, see *note The Collection of Value Types: Union Decl. In particular it produces a genuine `union'(1), which have a few specific features in C++. - The type `YYSTYPE' is defined but its use is discouraged: rather you should refer to the parser's encapsulated type `yy::parser::semantic_type'. - Non POD (Plain Old Data) types cannot be used. C++ forbids any instance of classes with constructors in unions: only _pointers_ to such objects are allowed. Because objects have to be stored via pointers, memory is not reclaimed automatically: using the `%destructor' directive is the only means to avoid leaks. *Note Freeing Discarded Symbols: Destructor Decl. ---------- Footnotes ---------- (1) In the future techniques to allow complex types within pseudo-unions (similar to Boost variants) might be implemented to alleviate these issues.  File: bison.info, Node: C++ Location Values, Next: C++ Parser Interface, Prev: C++ Semantic Values, Up: C++ Parsers 10.1.3 C++ Location Values -------------------------- When the directive `%locations' is used, the C++ parser supports location tracking, see *note Tracking Locations::. Two auxiliary classes define a `position', a single point in a file, and a `location', a range composed of a pair of `position's (possibly spanning several files). In this section `uint' is an abbreviation for `unsigned int': in genuine code only the latter is used. * Menu: * C++ position:: One point in the source file * C++ location:: Two points in the source file  File: bison.info, Node: C++ position, Next: C++ location, Up: C++ Location Values 10.1.3.1 C++ `position' ....................... -- Constructor on position: position (std::string* FILE = 0, uint LINE = 1, uint COL = 1) Create a `position' denoting a given point. Note that `file' is not reclaimed when the `position' is destroyed: memory managed must be handled elsewhere. -- Method on position: void initialize (std::string* FILE = 0, uint LINE = 1, uint COL = 1) Reset the position to the given values. -- Instance Variable of position: std::string* file The name of the file. It will always be handled as a pointer, the parser will never duplicate nor deallocate it. As an experimental feature you may change it to `TYPE*' using `%define filename_type "TYPE"'. -- Instance Variable of position: uint line The line, starting at 1. -- Method on position: uint lines (int HEIGHT = 1) Advance by HEIGHT lines, resetting the column number. -- Instance Variable of position: uint column The column, starting at 1. -- Method on position: uint columns (int WIDTH = 1) Advance by WIDTH columns, without changing the line number. -- Method on position: position& operator+= (int WIDTH) -- Method on position: position operator+ (int WIDTH) -- Method on position: position& operator-= (int WIDTH) -- Method on position: position operator- (int WIDTH) Various forms of syntactic sugar for `columns'. -- Method on position: bool operator== (const position& THAT) -- Method on position: bool operator!= (const position& THAT) Whether `*this' and `that' denote equal/different positions. -- Function: std::ostream& operator<< (std::ostream& O, const position& P) Report P on O like this: `FILE:LINE.COLUMN', or `LINE.COLUMN' if FILE is null.  File: bison.info, Node: C++ location, Prev: C++ position, Up: C++ Location Values 10.1.3.2 C++ `location' ....................... -- Constructor on location: location (const position& BEGIN, const position& END) Create a `Location' from the endpoints of the range. -- Constructor on location: location (const position& POS = position()) -- Constructor on location: location (std::string* FILE, uint LINE, uint COL) Create a `Location' denoting an empty range located at a given point. -- Method on location: void initialize (std::string* FILE = 0, uint LINE = 1, uint COL = 1) Reset the location to an empty range at the given values. -- Instance Variable of location: position begin -- Instance Variable of location: position end The first, inclusive, position of the range, and the first beyond. -- Method on location: uint columns (int WIDTH = 1) -- Method on location: uint lines (int HEIGHT = 1) Advance the `end' position. -- Method on location: location operator+ (const location& END) -- Method on location: location operator+ (int WIDTH) -- Method on location: location operator+= (int WIDTH) Various forms of syntactic sugar. -- Method on location: void step () Move `begin' onto `end'. -- Method on location: bool operator== (const location& THAT) -- Method on location: bool operator!= (const location& THAT) Whether `*this' and `that' denote equal/different ranges of positions. -- Function: std::ostream& operator<< (std::ostream& O, const location& P) Report P on O, taking care of special cases such as: no `filename' defined, or equal filename/line or column.  File: bison.info, Node: C++ Parser Interface, Next: C++ Scanner Interface, Prev: C++ Location Values, Up: C++ Parsers 10.1.4 C++ Parser Interface --------------------------- The output files `OUTPUT.hh' and `OUTPUT.cc' declare and define the parser class in the namespace `yy'. The class name defaults to `parser', but may be changed using `%define parser_class_name "NAME"'. The interface of this class is detailed below. It can be extended using the `%parse-param' feature: its semantics is slightly changed since it describes an additional member of the parser class, and an additional argument for its constructor. -- Type of parser: semantic_type -- Type of parser: location_type The types for semantics value and locations. -- Type of parser: token A structure that contains (only) the `yytokentype' enumeration, which defines the tokens. To refer to the token `FOO', use `yy::parser::token::FOO'. The scanner can use `typedef yy::parser::token token;' to "import" the token enumeration (*note Calc++ Scanner::). -- Method on parser: parser (TYPE1 ARG1, ...) Build a new parser object. There are no arguments by default, unless `%parse-param {TYPE1 ARG1}' was used. -- Method on parser: int parse () Run the syntactic analysis, and return 0 on success, 1 otherwise. -- Method on parser: std::ostream& debug_stream () -- Method on parser: void set_debug_stream (std::ostream& O) Get or set the stream used for tracing the parsing. It defaults to `std::cerr'. -- Method on parser: debug_level_type debug_level () -- Method on parser: void set_debug_level (debug_level L) Get or set the tracing level. Currently its value is either 0, no trace, or nonzero, full tracing. -- Method on parser: void error (const location_type& L, const std::string& M) The definition for this member function must be supplied by the user: the parser uses it to report a parser error occurring at L, described by M.  File: bison.info, Node: C++ Scanner Interface, Next: A Complete C++ Example, Prev: C++ Parser Interface, Up: C++ Parsers 10.1.5 C++ Scanner Interface ---------------------------- The parser invokes the scanner by calling `yylex'. Contrary to C parsers, C++ parsers are always pure: there is no point in using the `%define api.pure' directive. Therefore the interface is as follows. -- Method on parser: int yylex (semantic_type* YYLVAL, location_type* YYLLOC, TYPE1 ARG1, ...) Return the next token. Its type is the return value, its semantic value and location being YYLVAL and YYLLOC. Invocations of `%lex-param {TYPE1 ARG1}' yield additional arguments.  File: bison.info, Node: A Complete C++ Example, Prev: C++ Scanner Interface, Up: C++ Parsers 10.1.6 A Complete C++ Example ----------------------------- This section demonstrates the use of a C++ parser with a simple but complete example. This example should be available on your system, ready to compile, in the directory "../bison/examples/calc++". It focuses on the use of Bison, therefore the design of the various C++ classes is very naive: no accessors, no encapsulation of members etc. We will use a Lex scanner, and more precisely, a Flex scanner, to demonstrate the various interaction. A hand written scanner is actually easier to interface with. * Menu: * Calc++ --- C++ Calculator:: The specifications * Calc++ Parsing Driver:: An active parsing context * Calc++ Parser:: A parser class * Calc++ Scanner:: A pure C++ Flex scanner * Calc++ Top Level:: Conducting the band  File: bison.info, Node: Calc++ --- C++ Calculator, Next: Calc++ Parsing Driver, Up: A Complete C++ Example 10.1.6.1 Calc++ -- C++ Calculator ................................. Of course the grammar is dedicated to arithmetics, a single expression, possibly preceded by variable assignments. An environment containing possibly predefined variables such as `one' and `two', is exchanged with the parser. An example of valid input follows. three := 3 seven := one + two * three seven * seven  File: bison.info, Node: Calc++ Parsing Driver, Next: Calc++ Parser, Prev: Calc++ --- C++ Calculator, Up: A Complete C++ Example 10.1.6.2 Calc++ Parsing Driver .............................. To support a pure interface with the parser (and the scanner) the technique of the "parsing context" is convenient: a structure containing all the data to exchange. Since, in addition to simply launch the parsing, there are several auxiliary tasks to execute (open the file for parsing, instantiate the parser etc.), we recommend transforming the simple parsing context structure into a fully blown "parsing driver" class. The declaration of this driver class, `calc++-driver.hh', is as follows. The first part includes the CPP guard and imports the required standard library components, and the declaration of the parser class. #ifndef CALCXX_DRIVER_HH # define CALCXX_DRIVER_HH # include # include # include "calc++-parser.hh" Then comes the declaration of the scanning function. Flex expects the signature of `yylex' to be defined in the macro `YY_DECL', and the C++ parser expects it to be declared. We can factor both as follows. // Tell Flex the lexer's prototype ... # define YY_DECL \ yy::calcxx_parser::token_type \ yylex (yy::calcxx_parser::semantic_type* yylval, \ yy::calcxx_parser::location_type* yylloc, \ calcxx_driver& driver) // ... and declare it for the parser's sake. YY_DECL; The `calcxx_driver' class is then declared with its most obvious members. // Conducting the whole scanning and parsing of Calc++. class calcxx_driver { public: calcxx_driver (); virtual ~calcxx_driver (); std::map variables; int result; To encapsulate the coordination with the Flex scanner, it is useful to have two members function to open and close the scanning phase. // Handling the scanner. void scan_begin (); void scan_end (); bool trace_scanning; Similarly for the parser itself. // Run the parser. Return 0 on success. int parse (const std::string& f); std::string file; bool trace_parsing; To demonstrate pure handling of parse errors, instead of simply dumping them on the standard error output, we will pass them to the compiler driver using the following two member functions. Finally, we close the class declaration and CPP guard. // Error handling. void error (const yy::location& l, const std::string& m); void error (const std::string& m); }; #endif // ! CALCXX_DRIVER_HH The implementation of the driver is straightforward. The `parse' member function deserves some attention. The `error' functions are simple stubs, they should actually register the located error messages and set error state. #include "calc++-driver.hh" #include "calc++-parser.hh" calcxx_driver::calcxx_driver () : trace_scanning (false), trace_parsing (false) { variables["one"] = 1; variables["two"] = 2; } calcxx_driver::~calcxx_driver () { } int calcxx_driver::parse (const std::string &f) { file = f; scan_begin (); yy::calcxx_parser parser (*this); parser.set_debug_level (trace_parsing); int res = parser.parse (); scan_end (); return res; } void calcxx_driver::error (const yy::location& l, const std::string& m) { std::cerr << l << ": " << m << std::endl; } void calcxx_driver::error (const std::string& m) { std::cerr << m << std::endl; }  File: bison.info, Node: Calc++ Parser, Next: Calc++ Scanner, Prev: Calc++ Parsing Driver, Up: A Complete C++ Example 10.1.6.3 Calc++ Parser ...................... The grammar file `calc++-parser.yy' starts by asking for the C++ deterministic parser skeleton, the creation of the parser header file, and specifies the name of the parser class. Because the C++ skeleton changed several times, it is safer to require the version you designed the grammar for. %skeleton "lalr1.cc" /* -*- C++ -*- */ %require "2.6.1-dirty" %defines %define parser_class_name "calcxx_parser" Then come the declarations/inclusions needed to define the `%union'. Because the parser uses the parsing driver and reciprocally, both cannot include the header of the other. Because the driver's header needs detailed knowledge about the parser class (in particular its inner types), it is the parser's header which will simply use a forward declaration of the driver. *Note %code Summary::. %code requires { # include class calcxx_driver; } The driver is passed by reference to the parser and to the scanner. This provides a simple but effective pure interface, not relying on global variables. // The parsing context. %parse-param { calcxx_driver& driver } %lex-param { calcxx_driver& driver } Then we request the location tracking feature, and initialize the first location's file name. Afterward new locations are computed relatively to the previous locations: the file name will be automatically propagated. %locations %initial-action { // Initialize the initial location. @$.begin.filename = @$.end.filename = &driver.file; }; Use the two following directives to enable parser tracing and verbose error messages. However, verbose error messages can contain incorrect information (*note LAC::). %debug %error-verbose Semantic values cannot use "real" objects, but only pointers to them. // Symbols. %union { int ival; std::string *sval; }; The code between `%code {' and `}' is output in the `*.cc' file; it needs detailed knowledge about the driver. %code { # include "calc++-driver.hh" } The token numbered as 0 corresponds to end of file; the following line allows for nicer error messages referring to "end of file" instead of "$end". Similarly user friendly named are provided for each symbol. Note that the tokens names are prefixed by `TOKEN_' to avoid name clashes. %token END 0 "end of file" %token ASSIGN ":=" %token IDENTIFIER "identifier" %token NUMBER "number" %type exp To enable memory deallocation during error recovery, use `%destructor'. %printer { yyoutput << *$$; } "identifier" %destructor { delete $$; } "identifier" %printer { yyoutput << $$; } The grammar itself is straightforward. %% %start unit; unit: assignments exp { driver.result = $2; }; assignments: /* Nothing. */ {} | assignments assignment {}; assignment: "identifier" ":=" exp { driver.variables[*$1] = $3; delete $1; }; %left '+' '-'; %left '*' '/'; exp: exp '+' exp { $$ = $1 + $3; } | exp '-' exp { $$ = $1 - $3; } | exp '*' exp { $$ = $1 * $3; } | exp '/' exp { $$ = $1 / $3; } | "identifier" { $$ = driver.variables[*$1]; delete $1; } | "number" { $$ = $1; }; %% Finally the `error' member function registers the errors to the driver. void yy::calcxx_parser::error (const yy::calcxx_parser::location_type& l, const std::string& m) { driver.error (l, m); }  File: bison.info, Node: Calc++ Scanner, Next: Calc++ Top Level, Prev: Calc++ Parser, Up: A Complete C++ Example 10.1.6.4 Calc++ Scanner ....................... The Flex scanner first includes the driver declaration, then the parser's to get the set of defined tokens. %{ /* -*- C++ -*- */ # include # include # include # include # include "calc++-driver.hh" # include "calc++-parser.hh" /* Work around an incompatibility in flex (at least versions 2.5.31 through 2.5.33): it generates code that does not conform to C89. See Debian bug 333231 . */ # undef yywrap # define yywrap() 1 /* By default yylex returns int, we use token_type. Unfortunately yyterminate by default returns 0, which is not of token_type. */ #define yyterminate() return token::END %} Because there is no `#include'-like feature we don't need `yywrap', we don't need `unput' either, and we parse an actual file, this is not an interactive session with the user. Finally we enable the scanner tracing features. %option noyywrap nounput batch debug Abbreviations allow for more readable rules. id [a-zA-Z][a-zA-Z_0-9]* int [0-9]+ blank [ \t] The following paragraph suffices to track locations accurately. Each time `yylex' is invoked, the begin position is moved onto the end position. Then when a pattern is matched, the end position is advanced of its width. In case it matched ends of lines, the end cursor is adjusted, and each time blanks are matched, the begin cursor is moved onto the end cursor to effectively ignore the blanks preceding tokens. Comments would be treated equally. %{ # define YY_USER_ACTION yylloc->columns (yyleng); %} %% %{ yylloc->step (); %} {blank}+ yylloc->step (); [\n]+ yylloc->lines (yyleng); yylloc->step (); The rules are simple, just note the use of the driver to report errors. It is convenient to use a typedef to shorten `yy::calcxx_parser::token::identifier' into `token::identifier' for instance. %{ typedef yy::calcxx_parser::token token; %} /* Convert ints to the actual type of tokens. */ [-+*/] return yy::calcxx_parser::token_type (yytext[0]); ":=" return token::ASSIGN; {int} { errno = 0; long n = strtol (yytext, NULL, 10); if (! (INT_MIN <= n && n <= INT_MAX && errno != ERANGE)) driver.error (*yylloc, "integer is out of range"); yylval->ival = n; return token::NUMBER; } {id} yylval->sval = new std::string (yytext); return token::IDENTIFIER; . driver.error (*yylloc, "invalid character"); %% Finally, because the scanner related driver's member function depend on the scanner's data, it is simpler to implement them in this file. void calcxx_driver::scan_begin () { yy_flex_debug = trace_scanning; if (file.empty () || file == "-") yyin = stdin; else if (!(yyin = fopen (file.c_str (), "r"))) { error ("cannot open " + file + ": " + strerror(errno)); exit (EXIT_FAILURE); } } void calcxx_driver::scan_end () { fclose (yyin); }  File: bison.info, Node: Calc++ Top Level, Prev: Calc++ Scanner, Up: A Complete C++ Example 10.1.6.5 Calc++ Top Level ......................... The top level file, `calc++.cc', poses no problem. #include #include "calc++-driver.hh" int main (int argc, char *argv[]) { calcxx_driver driver; for (int i = 1; i < argc; ++i) if (argv[i] == std::string ("-p")) driver.trace_parsing = true; else if (argv[i] == std::string ("-s")) driver.trace_scanning = true; else if (!driver.parse (argv[i])) std::cout << driver.result << std::endl; }  File: bison.info, Node: Java Parsers, Prev: C++ Parsers, Up: Other Languages 10.2 Java Parsers ================= * Menu: * Java Bison Interface:: Asking for Java parser generation * Java Semantic Values:: %type and %token vs. Java * Java Location Values:: The position and location classes * Java Parser Interface:: Instantiating and running the parser * Java Scanner Interface:: Specifying the scanner for the parser * Java Action Features:: Special features for use in actions * Java Differences:: Differences between C/C++ and Java Grammars * Java Declarations Summary:: List of Bison declarations used with Java  File: bison.info, Node: Java Bison Interface, Next: Java Semantic Values, Up: Java Parsers 10.2.1 Java Bison Interface --------------------------- (The current Java interface is experimental and may evolve. More user feedback will help to stabilize it.) The Java parser skeletons are selected using the `%language "Java"' directive or the `-L java'/`--language=java' option. When generating a Java parser, `bison BASENAME.y' will create a single Java source file named `BASENAME.java' containing the parser implementation. Using a grammar file without a `.y' suffix is currently broken. The basename of the parser implementation file can be changed by the `%file-prefix' directive or the `-p'/`--name-prefix' option. The entire parser implementation file name can be changed by the `%output' directive or the `-o'/`--output' option. The parser implementation file contains a single class for the parser. You can create documentation for generated parsers using Javadoc. Contrary to C parsers, Java parsers do not use global variables; the state of the parser is always local to an instance of the parser class. Therefore, all Java parsers are "pure", and the `%pure-parser' and `%define api.pure' directives does not do anything when used in Java. Push parsers are currently unsupported in Java and `%define api.push-pull' have no effect. GLR parsers are currently unsupported in Java. Do not use the `glr-parser' directive. No header file can be generated for Java parsers. Do not use the `%defines' directive or the `-d'/`--defines' options. Currently, support for debugging and verbose errors are always compiled in. Thus the `%debug' and `%token-table' directives and the `-t'/`--debug' and `-k'/`--token-table' options have no effect. This may change in the future to eliminate unused code in the generated parser, so use `%debug' and `%verbose-error' explicitly if needed. Also, in the future the `%token-table' directive might enable a public interface to access the token names and codes.  File: bison.info, Node: Java Semantic Values, Next: Java Location Values, Prev: Java Bison Interface, Up: Java Parsers 10.2.2 Java Semantic Values --------------------------- There is no `%union' directive in Java parsers. Instead, the semantic values' types (class names) should be specified in the `%type' or `%token' directive: %type expr assignment_expr term factor %type number By default, the semantic stack is declared to have `Object' members, which means that the class types you specify can be of any class. To improve the type safety of the parser, you can declare the common superclass of all the semantic values using the `%define stype' directive. For example, after the following declaration: %define stype "ASTNode" any `%type' or `%token' specifying a semantic type which is not a subclass of ASTNode, will cause a compile-time error. Types used in the directives may be qualified with a package name. Primitive data types are accepted for Java version 1.5 or later. Note that in this case the autoboxing feature of Java 1.5 will be used. Generic types may not be used; this is due to a limitation in the implementation of Bison, and may change in future releases. Java parsers do not support `%destructor', since the language adopts garbage collection. The parser will try to hold references to semantic values for as little time as needed. Java parsers do not support `%printer', as `toString()' can be used to print the semantic values. This however may change (in a backwards-compatible way) in future versions of Bison.  File: bison.info, Node: Java Location Values, Next: Java Parser Interface, Prev: Java Semantic Values, Up: Java Parsers 10.2.3 Java Location Values --------------------------- When the directive `%locations' is used, the Java parser supports location tracking, see *note Tracking Locations::. An auxiliary user-defined class defines a "position", a single point in a file; Bison itself defines a class representing a "location", a range composed of a pair of positions (possibly spanning several files). The location class is an inner class of the parser; the name is `Location' by default, and may also be renamed using `%define location_type "CLASS-NAME"'. The location class treats the position as a completely opaque value. By default, the class name is `Position', but this can be changed with `%define position_type "CLASS-NAME"'. This class must be supplied by the user. -- Instance Variable of Location: Position begin -- Instance Variable of Location: Position end The first, inclusive, position of the range, and the first beyond. -- Constructor on Location: Location (Position LOC) Create a `Location' denoting an empty range located at a given point. -- Constructor on Location: Location (Position BEGIN, Position END) Create a `Location' from the endpoints of the range. -- Method on Location: String toString () Prints the range represented by the location. For this to work properly, the position class should override the `equals' and `toString' methods appropriately.  File: bison.info, Node: Java Parser Interface, Next: Java Scanner Interface, Prev: Java Location Values, Up: Java Parsers 10.2.4 Java Parser Interface ---------------------------- The name of the generated parser class defaults to `YYParser'. The `YY' prefix may be changed using the `%name-prefix' directive or the `-p'/`--name-prefix' option. Alternatively, use `%define parser_class_name "NAME"' to give a custom name to the class. The interface of this class is detailed below. By default, the parser class has package visibility. A declaration `%define public' will change to public visibility. Remember that, according to the Java language specification, the name of the `.java' file should match the name of the class in this case. Similarly, you can use `abstract', `final' and `strictfp' with the `%define' declaration to add other modifiers to the parser class. The Java package name of the parser class can be specified using the `%define package' directive. The superclass and the implemented interfaces of the parser class can be specified with the `%define extends' and `%define implements' directives. The parser class defines an inner class, `Location', that is used for location tracking (see *note Java Location Values::), and a inner interface, `Lexer' (see *note Java Scanner Interface::). Other than these inner class/interface, and the members described in the interface below, all the other members and fields are preceded with a `yy' or `YY' prefix to avoid clashes with user code. The parser class can be extended using the `%parse-param' directive. Each occurrence of the directive will add a `protected final' field to the parser class, and an argument to its constructor, which initialize them automatically. Token names defined by `%token' and the predefined `EOF' token name are added as constant fields to the parser class. -- Constructor on YYParser: YYParser (LEX_PARAM, ..., PARSE_PARAM, ...) Build a new parser object with embedded `%code lexer'. There are no parameters, unless `%parse-param's and/or `%lex-param's are used. -- Constructor on YYParser: YYParser (Lexer LEXER, PARSE_PARAM, ...) Build a new parser object using the specified scanner. There are no additional parameters unless `%parse-param's are used. If the scanner is defined by `%code lexer', this constructor is declared `protected' and is called automatically with a scanner created with the correct `%lex-param's. -- Method on YYParser: boolean parse () Run the syntactic analysis, and return `true' on success, `false' otherwise. -- Method on YYParser: boolean recovering () During the syntactic analysis, return `true' if recovering from a syntax error. *Note Error Recovery::. -- Method on YYParser: java.io.PrintStream getDebugStream () -- Method on YYParser: void setDebugStream (java.io.printStream O) Get or set the stream used for tracing the parsing. It defaults to `System.err'. -- Method on YYParser: int getDebugLevel () -- Method on YYParser: void setDebugLevel (int L) Get or set the tracing level. Currently its value is either 0, no trace, or nonzero, full tracing.  File: bison.info, Node: Java Scanner Interface, Next: Java Action Features, Prev: Java Parser Interface, Up: Java Parsers 10.2.5 Java Scanner Interface ----------------------------- There are two possible ways to interface a Bison-generated Java parser with a scanner: the scanner may be defined by `%code lexer', or defined elsewhere. In either case, the scanner has to implement the `Lexer' inner interface of the parser class. In the first case, the body of the scanner class is placed in `%code lexer' blocks. If you want to pass parameters from the parser constructor to the scanner constructor, specify them with `%lex-param'; they are passed before `%parse-param's to the constructor. In the second case, the scanner has to implement the `Lexer' interface, which is defined within the parser class (e.g., `YYParser.Lexer'). The constructor of the parser object will then accept an object implementing the interface; `%lex-param' is not used in this case. In both cases, the scanner has to implement the following methods. -- Method on Lexer: void yyerror (Location LOC, String MSG) This method is defined by the user to emit an error message. The first parameter is omitted if location tracking is not active. Its type can be changed using `%define location_type "CLASS-NAME".' -- Method on Lexer: int yylex () Return the next token. Its type is the return value, its semantic value and location are saved and returned by the their methods in the interface. Use `%define lex_throws' to specify any uncaught exceptions. Default is `java.io.IOException'. -- Method on Lexer: Position getStartPos () -- Method on Lexer: Position getEndPos () Return respectively the first position of the last token that `yylex' returned, and the first position beyond it. These methods are not needed unless location tracking is active. The return type can be changed using `%define position_type "CLASS-NAME".' -- Method on Lexer: Object getLVal () Return the semantic value of the last token that yylex returned. The return type can be changed using `%define stype "CLASS-NAME".'  File: bison.info, Node: Java Action Features, Next: Java Differences, Prev: Java Scanner Interface, Up: Java Parsers 10.2.6 Special Features for Use in Java Actions ----------------------------------------------- The following special constructs can be uses in Java actions. Other analogous C action features are currently unavailable for Java. Use `%define throws' to specify any uncaught exceptions from parser actions, and initial actions specified by `%initial-action'. -- Variable: $N The semantic value for the Nth component of the current rule. This may not be assigned to. *Note Java Semantic Values::. -- Variable: $N Like `$N' but specifies a alternative type TYPEALT. *Note Java Semantic Values::. -- Variable: $$ The semantic value for the grouping made by the current rule. As a value, this is in the base type (`Object' or as specified by `%define stype') as in not cast to the declared subtype because casts are not allowed on the left-hand side of Java assignments. Use an explicit Java cast if the correct subtype is needed. *Note Java Semantic Values::. -- Variable: $$ Same as `$$' since Java always allow assigning to the base type. Perhaps we should use this and `$<>$' for the value and `$$' for setting the value but there is currently no easy way to distinguish these constructs. *Note Java Semantic Values::. -- Variable: @N The location information of the Nth component of the current rule. This may not be assigned to. *Note Java Location Values::. -- Variable: @$ The location information of the grouping made by the current rule. *Note Java Location Values::. -- Statement: return YYABORT `;' Return immediately from the parser, indicating failure. *Note Java Parser Interface::. -- Statement: return YYACCEPT `;' Return immediately from the parser, indicating success. *Note Java Parser Interface::. -- Statement: return YYERROR `;' Start error recovery (without printing an error message). *Note Error Recovery::. -- Function: boolean recovering () Return whether error recovery is being done. In this state, the parser reads token until it reaches a known state, and then restarts normal operation. *Note Error Recovery::. -- Function: protected void yyerror (String msg) -- Function: protected void yyerror (Position pos, String msg) -- Function: protected void yyerror (Location loc, String msg) Print an error message using the `yyerror' method of the scanner instance in use.  File: bison.info, Node: Java Differences, Next: Java Declarations Summary, Prev: Java Action Features, Up: Java Parsers 10.2.7 Differences between C/C++ and Java Grammars -------------------------------------------------- The different structure of the Java language forces several differences between C/C++ grammars, and grammars designed for Java parsers. This section summarizes these differences. * Java lacks a preprocessor, so the `YYERROR', `YYACCEPT', `YYABORT' symbols (*note Table of Symbols::) cannot obviously be macros. Instead, they should be preceded by `return' when they appear in an action. The actual definition of these symbols is opaque to the Bison grammar, and it might change in the future. The only meaningful operation that you can do, is to return them. *Note Java Action Features::. Note that of these three symbols, only `YYACCEPT' and `YYABORT' will cause a return from the `yyparse' method(1). * Java lacks unions, so `%union' has no effect. Instead, semantic values have a common base type: `Object' or as specified by `%define stype'. Angle brackets on `%token', `type', `$N' and `$$' specify subtypes rather than fields of an union. The type of `$$', even with angle brackets, is the base type since Java casts are not allow on the left-hand side of assignments. Also, `$N' and `@N' are not allowed on the left-hand side of assignments. *Note Java Semantic Values::, and *note Java Action Features::. * The prologue declarations have a different meaning than in C/C++ code. `%code imports' blocks are placed at the beginning of the Java source code. They may include copyright notices. For a `package' declarations, it is suggested to use `%define package' instead. unqualified `%code' blocks are placed inside the parser class. `%code lexer' blocks, if specified, should include the implementation of the scanner. If there is no such block, the scanner can be any class that implements the appropriate interface (*note Java Scanner Interface::). Other `%code' blocks are not supported in Java parsers. In particular, `%{ ... %}' blocks should not be used and may give an error in future versions of Bison. The epilogue has the same meaning as in C/C++ code and it can be used to define other classes used by the parser _outside_ the parser class. ---------- Footnotes ---------- (1) Java parsers include the actions in a separate method than `yyparse' in order to have an intuitive syntax that corresponds to these C macros.  File: bison.info, Node: Java Declarations Summary, Prev: Java Differences, Up: Java Parsers 10.2.8 Java Declarations Summary -------------------------------- This summary only include declarations specific to Java or have special meaning when used in a Java parser. -- Directive: %language "Java" Generate a Java class for the parser. -- Directive: %lex-param {TYPE NAME} A parameter for the lexer class defined by `%code lexer' _only_, added as parameters to the lexer constructor and the parser constructor that _creates_ a lexer. Default is none. *Note Java Scanner Interface::. -- Directive: %name-prefix "PREFIX" The prefix of the parser class name `PREFIXParser' if `%define parser_class_name' is not used. Default is `YY'. *Note Java Bison Interface::. -- Directive: %parse-param {TYPE NAME} A parameter for the parser class added as parameters to constructor(s) and as fields initialized by the constructor(s). Default is none. *Note Java Parser Interface::. -- Directive: %token TOKEN ... Declare tokens. Note that the angle brackets enclose a Java _type_. *Note Java Semantic Values::. -- Directive: %type NONTERMINAL ... Declare the type of nonterminals. Note that the angle brackets enclose a Java _type_. *Note Java Semantic Values::. -- Directive: %code { CODE ... } Code appended to the inside of the parser class. *Note Java Differences::. -- Directive: %code imports { CODE ... } Code inserted just after the `package' declaration. *Note Java Differences::. -- Directive: %code lexer { CODE ... } Code added to the body of a inner lexer class within the parser class. *Note Java Scanner Interface::. -- Directive: %% CODE ... Code (after the second `%%') appended to the end of the file, _outside_ the parser class. *Note Java Differences::. -- Directive: %{ CODE ... %} Not supported. Use `%code import' instead. *Note Java Differences::. -- Directive: %define abstract Whether the parser class is declared `abstract'. Default is false. *Note Java Bison Interface::. -- Directive: %define extends "SUPERCLASS" The superclass of the parser class. Default is none. *Note Java Bison Interface::. -- Directive: %define final Whether the parser class is declared `final'. Default is false. *Note Java Bison Interface::. -- Directive: %define implements "INTERFACES" The implemented interfaces of the parser class, a comma-separated list. Default is none. *Note Java Bison Interface::. -- Directive: %define lex_throws "EXCEPTIONS" The exceptions thrown by the `yylex' method of the lexer, a comma-separated list. Default is `java.io.IOException'. *Note Java Scanner Interface::. -- Directive: %define location_type "CLASS" The name of the class used for locations (a range between two positions). This class is generated as an inner class of the parser class by `bison'. Default is `Location'. *Note Java Location Values::. -- Directive: %define package "PACKAGE" The package to put the parser class in. Default is none. *Note Java Bison Interface::. -- Directive: %define parser_class_name "NAME" The name of the parser class. Default is `YYParser' or `NAME-PREFIXParser'. *Note Java Bison Interface::. -- Directive: %define position_type "CLASS" The name of the class used for positions. This class must be supplied by the user. Default is `Position'. *Note Java Location Values::. -- Directive: %define public Whether the parser class is declared `public'. Default is false. *Note Java Bison Interface::. -- Directive: %define stype "CLASS" The base type of semantic values. Default is `Object'. *Note Java Semantic Values::. -- Directive: %define strictfp Whether the parser class is declared `strictfp'. Default is false. *Note Java Bison Interface::. -- Directive: %define throws "EXCEPTIONS" The exceptions thrown by user-supplied parser actions and `%initial-action', a comma-separated list. Default is none. *Note Java Parser Interface::.  File: bison.info, Node: FAQ, Next: Table of Symbols, Prev: Other Languages, Up: Top 11 Frequently Asked Questions ***************************** Several questions about Bison come up occasionally. Here some of them are addressed. * Menu: * Memory Exhausted:: Breaking the Stack Limits * How Can I Reset the Parser:: `yyparse' Keeps some State * Strings are Destroyed:: `yylval' Loses Track of Strings * Implementing Gotos/Loops:: Control Flow in the Calculator * Multiple start-symbols:: Factoring closely related grammars * Secure? Conform?:: Is Bison POSIX safe? * I can't build Bison:: Troubleshooting * Where can I find help?:: Troubleshouting * Bug Reports:: Troublereporting * More Languages:: Parsers in C++, Java, and so on * Beta Testing:: Experimenting development versions * Mailing Lists:: Meeting other Bison users  File: bison.info, Node: Memory Exhausted, Next: How Can I Reset the Parser, Up: FAQ 11.1 Memory Exhausted ===================== My parser returns with error with a `memory exhausted' message. What can I do? This question is already addressed elsewhere, see *note Recursive Rules: Recursion.  File: bison.info, Node: How Can I Reset the Parser, Next: Strings are Destroyed, Prev: Memory Exhausted, Up: FAQ 11.2 How Can I Reset the Parser =============================== The following phenomenon has several symptoms, resulting in the following typical questions: I invoke `yyparse' several times, and on correct input it works properly; but when a parse error is found, all the other calls fail too. How can I reset the error flag of `yyparse'? or My parser includes support for an `#include'-like feature, in which case I run `yyparse' from `yyparse'. This fails although I did specify `%define api.pure'. These problems typically come not from Bison itself, but from Lex-generated scanners. Because these scanners use large buffers for speed, they might not notice a change of input file. As a demonstration, consider the following source file, `first-line.l': %{ #include #include %} %% .*\n ECHO; return 1; %% int yyparse (char const *file) { yyin = fopen (file, "r"); if (!yyin) { perror ("fopen"); exit (EXIT_FAILURE); } /* One token only. */ yylex (); if (fclose (yyin) != 0) { perror ("fclose"); exit (EXIT_FAILURE); } return 0; } int main (void) { yyparse ("input"); yyparse ("input"); return 0; } If the file `input' contains input:1: Hello, input:2: World! then instead of getting the first line twice, you get: $ flex -ofirst-line.c first-line.l $ gcc -ofirst-line first-line.c -ll $ ./first-line input:1: Hello, input:2: World! Therefore, whenever you change `yyin', you must tell the Lex-generated scanner to discard its current buffer and switch to the new one. This depends upon your implementation of Lex; see its documentation for more. For Flex, it suffices to call `YY_FLUSH_BUFFER' after each change to `yyin'. If your Flex-generated scanner needs to read from several input streams to handle features like include files, you might consider using Flex functions like `yy_switch_to_buffer' that manipulate multiple input buffers. If your Flex-generated scanner uses start conditions (*note Start conditions: (flex)Start conditions.), you might also want to reset the scanner's state, i.e., go back to the initial start condition, through a call to `BEGIN (0)'.  File: bison.info, Node: Strings are Destroyed, Next: Implementing Gotos/Loops, Prev: How Can I Reset the Parser, Up: FAQ 11.3 Strings are Destroyed ========================== My parser seems to destroy old strings, or maybe it loses track of them. Instead of reporting `"foo", "bar"', it reports `"bar", "bar"', or even `"foo\nbar", "bar"'. This error is probably the single most frequent "bug report" sent to Bison lists, but is only concerned with a misunderstanding of the role of the scanner. Consider the following Lex code: %{ #include char *yylval = NULL; %} %% .* yylval = yytext; return 1; \n /* IGNORE */ %% int main () { /* Similar to using $1, $2 in a Bison action. */ char *fst = (yylex (), yylval); char *snd = (yylex (), yylval); printf ("\"%s\", \"%s\"\n", fst, snd); return 0; } If you compile and run this code, you get: $ flex -osplit-lines.c split-lines.l $ gcc -osplit-lines split-lines.c -ll $ printf 'one\ntwo\n' | ./split-lines "one two", "two" this is because `yytext' is a buffer provided for _reading_ in the action, but if you want to keep it, you have to duplicate it (e.g., using `strdup'). Note that the output may depend on how your implementation of Lex handles `yytext'. For instance, when given the Lex compatibility option `-l' (which triggers the option `%array') Flex generates a different behavior: $ flex -l -osplit-lines.c split-lines.l $ gcc -osplit-lines split-lines.c -ll $ printf 'one\ntwo\n' | ./split-lines "two", "two"  File: bison.info, Node: Implementing Gotos/Loops, Next: Multiple start-symbols, Prev: Strings are Destroyed, Up: FAQ 11.4 Implementing Gotos/Loops ============================= My simple calculator supports variables, assignments, and functions, but how can I implement gotos, or loops? Although very pedagogical, the examples included in the document blur the distinction to make between the parser--whose job is to recover the structure of a text and to transmit it to subsequent modules of the program--and the processing (such as the execution) of this structure. This works well with so called straight line programs, i.e., precisely those that have a straightforward execution model: execute simple instructions one after the others. If you want a richer model, you will probably need to use the parser to construct a tree that does represent the structure it has recovered; this tree is usually called the "abstract syntax tree", or "AST" for short. Then, walking through this tree, traversing it in various ways, will enable treatments such as its execution or its translation, which will result in an interpreter or a compiler. This topic is way beyond the scope of this manual, and the reader is invited to consult the dedicated literature.  File: bison.info, Node: Multiple start-symbols, Next: Secure? Conform?, Prev: Implementing Gotos/Loops, Up: FAQ 11.5 Multiple start-symbols =========================== I have several closely related grammars, and I would like to share their implementations. In fact, I could use a single grammar but with multiple entry points. Bison does not support multiple start-symbols, but there is a very simple means to simulate them. If `foo' and `bar' are the two pseudo start-symbols, then introduce two new tokens, say `START_FOO' and `START_BAR', and use them as switches from the real start-symbol: %token START_FOO START_BAR; %start start; start: START_FOO foo | START_BAR bar; These tokens prevents the introduction of new conflicts. As far as the parser goes, that is all that is needed. Now the difficult part is ensuring that the scanner will send these tokens first. If your scanner is hand-written, that should be straightforward. If your scanner is generated by Lex, them there is simple means to do it: recall that anything between `%{ ... %}' after the first `%%' is copied verbatim in the top of the generated `yylex' function. Make sure a variable `start_token' is available in the scanner (e.g., a global variable or using `%lex-param' etc.), and use the following: /* Prologue. */ %% %{ if (start_token) { int t = start_token; start_token = 0; return t; } %} /* The rules. */  File: bison.info, Node: Secure? Conform?, Next: I can't build Bison, Prev: Multiple start-symbols, Up: FAQ 11.6 Secure? Conform? ====================== Is Bison secure? Does it conform to POSIX? If you're looking for a guarantee or certification, we don't provide it. However, Bison is intended to be a reliable program that conforms to the POSIX specification for Yacc. If you run into problems, please send us a bug report.  File: bison.info, Node: I can't build Bison, Next: Where can I find help?, Prev: Secure? Conform?, Up: FAQ 11.7 I can't build Bison ======================== I can't build Bison because `make' complains that `msgfmt' is not found. What should I do? Like most GNU packages with internationalization support, that feature is turned on by default. If you have problems building in the `po' subdirectory, it indicates that your system's internationalization support is lacking. You can re-configure Bison with `--disable-nls' to turn off this support, or you can install GNU gettext from `ftp://ftp.gnu.org/gnu/gettext/' and re-configure Bison. See the file `ABOUT-NLS' for more information.  File: bison.info, Node: Where can I find help?, Next: Bug Reports, Prev: I can't build Bison, Up: FAQ 11.8 Where can I find help? =========================== I'm having trouble using Bison. Where can I find help? First, read this fine manual. Beyond that, you can send mail to . This mailing list is intended to be populated with people who are willing to answer questions about using and installing Bison. Please keep in mind that (most of) the people on the list have aspects of their lives which are not related to Bison (!), so you may not receive an answer to your question right away. This can be frustrating, but please try not to honk them off; remember that any help they provide is purely voluntary and out of the kindness of their hearts.  File: bison.info, Node: Bug Reports, Next: More Languages, Prev: Where can I find help?, Up: FAQ 11.9 Bug Reports ================ I found a bug. What should I include in the bug report? Before you send a bug report, make sure you are using the latest version. Check `ftp://ftp.gnu.org/pub/gnu/bison/' or one of its mirrors. Be sure to include the version number in your bug report. If the bug is present in the latest version but not in a previous version, try to determine the most recent version which did not contain the bug. If the bug is parser-related, you should include the smallest grammar you can which demonstrates the bug. The grammar file should also be complete (i.e., I should be able to run it through Bison without having to edit or add anything). The smaller and simpler the grammar, the easier it will be to fix the bug. Include information about your compilation environment, including your operating system's name and version and your compiler's name and version. If you have trouble compiling, you should also include a transcript of the build session, starting with the invocation of `configure'. Depending on the nature of the bug, you may be asked to send additional files as well (such as `config.h' or `config.cache'). Patches are most welcome, but not required. That is, do not hesitate to send a bug report just because you cannot provide a fix. Send bug reports to .  File: bison.info, Node: More Languages, Next: Beta Testing, Prev: Bug Reports, Up: FAQ 11.10 More Languages ==================== Will Bison ever have C++ and Java support? How about INSERT YOUR FAVORITE LANGUAGE HERE? C++ and Java support is there now, and is documented. We'd love to add other languages; contributions are welcome.  File: bison.info, Node: Beta Testing, Next: Mailing Lists, Prev: More Languages, Up: FAQ 11.11 Beta Testing ================== What is involved in being a beta tester? It's not terribly involved. Basically, you would download a test release, compile it, and use it to build and run a parser or two. After that, you would submit either a bug report or a message saying that everything is okay. It is important to report successes as well as failures because test releases eventually become mainstream releases, but only if they are adequately tested. If no one tests, development is essentially halted. Beta testers are particularly needed for operating systems to which the developers do not have easy access. They currently have easy access to recent GNU/Linux and Solaris versions. Reports about other operating systems are especially welcome.  File: bison.info, Node: Mailing Lists, Prev: Beta Testing, Up: FAQ 11.12 Mailing Lists =================== How do I join the help-bison and bug-bison mailing lists? See `http://lists.gnu.org/'.  File: bison.info, Node: Table of Symbols, Next: Glossary, Prev: FAQ, Up: Top Annexe A Bison Symbols ********************** -- Variable: @$ In an action, the location of the left-hand side of the rule. *Note Tracking Locations::. -- Variable: @N In an action, the location of the N-th symbol of the right-hand side of the rule. *Note Tracking Locations::. -- Variable: @NAME In an action, the location of a symbol addressed by name. *Note Tracking Locations::. -- Variable: @[NAME] In an action, the location of a symbol addressed by name. *Note Tracking Locations::. -- Variable: $$ In an action, the semantic value of the left-hand side of the rule. *Note Actions::. -- Variable: $N In an action, the semantic value of the N-th symbol of the right-hand side of the rule. *Note Actions::. -- Variable: $NAME In an action, the semantic value of a symbol addressed by name. *Note Actions::. -- Variable: $[NAME] In an action, the semantic value of a symbol addressed by name. *Note Actions::. -- Delimiter: %% Delimiter used to separate the grammar rule section from the Bison declarations section or the epilogue. *Note The Overall Layout of a Bison Grammar: Grammar Layout. -- Delimiter: %{CODE%} All code listed between `%{' and `%}' is copied verbatim to the parser implementation file. Such code forms the prologue of the grammar file. *Note Outline of a Bison Grammar: Grammar Outline. -- Construct: /*...*/ Comment delimiters, as in C. -- Delimiter: : Separates a rule's result from its components. *Note Syntax of Grammar Rules: Rules. -- Delimiter: ; Terminates a rule. *Note Syntax of Grammar Rules: Rules. -- Delimiter: | Separates alternate rules for the same result nonterminal. *Note Syntax of Grammar Rules: Rules. -- Directive: <*> Used to define a default tagged `%destructor' or default tagged `%printer'. This feature is experimental. More user feedback will help to determine whether it should become a permanent feature. *Note Freeing Discarded Symbols: Destructor Decl. -- Directive: <> Used to define a default tagless `%destructor' or default tagless `%printer'. This feature is experimental. More user feedback will help to determine whether it should become a permanent feature. *Note Freeing Discarded Symbols: Destructor Decl. -- Symbol: $accept The predefined nonterminal whose only rule is `$accept: START $end', where START is the start symbol. *Note The Start-Symbol: Start Decl. It cannot be used in the grammar. -- Directive: %code {CODE} -- Directive: %code QUALIFIER {CODE} Insert CODE verbatim into the output parser source at the default location or at the location specified by QUALIFIER. *Note %code Summary::. -- Directive: %debug Equip the parser for debugging. *Note Decl Summary::. -- Directive: %define VARIABLE -- Directive: %define VARIABLE VALUE -- Directive: %define VARIABLE "VALUE" Define a variable to adjust Bison's behavior. *Note %define Summary::. -- Directive: %defines Bison declaration to create a parser header file, which is usually meant for the scanner. *Note Decl Summary::. -- Directive: %defines DEFINES-FILE Same as above, but save in the file DEFINES-FILE. *Note Decl Summary::. -- Directive: %destructor Specify how the parser should reclaim the memory associated to discarded symbols. *Note Freeing Discarded Symbols: Destructor Decl. -- Directive: %dprec Bison declaration to assign a precedence to a rule that is used at parse time to resolve reduce/reduce conflicts. *Note Writing GLR Parsers: GLR Parsers. -- Symbol: $end The predefined token marking the end of the token stream. It cannot be used in the grammar. -- Symbol: error A token name reserved for error recovery. This token may be used in grammar rules so as to allow the Bison parser to recognize an error in the grammar without halting the process. In effect, a sentence containing an error may be recognized as valid. On a syntax error, the token `error' becomes the current lookahead token. Actions corresponding to `error' are then executed, and the lookahead token is reset to the token that originally caused the violation. *Note Error Recovery::. -- Directive: %error-verbose Bison declaration to request verbose, specific error message strings when `yyerror' is called. *Note Error Reporting::. -- Directive: %file-prefix "PREFIX" Bison declaration to set the prefix of the output files. *Note Decl Summary::. -- Directive: %glr-parser Bison declaration to produce a GLR parser. *Note Writing GLR Parsers: GLR Parsers. -- Directive: %initial-action Run user code before parsing. *Note Performing Actions before Parsing: Initial Action Decl. -- Directive: %language Specify the programming language for the generated parser. *Note Decl Summary::. -- Directive: %left Bison declaration to assign left associativity to token(s). *Note Operator Precedence: Precedence Decl. -- Directive: %lex-param {ARGUMENT-DECLARATION} Bison declaration to specifying an additional parameter that `yylex' should accept. *Note Calling Conventions for Pure Parsers: Pure Calling. -- Directive: %merge Bison declaration to assign a merging function to a rule. If there is a reduce/reduce conflict with a rule having the same merging function, the function is applied to the two semantic values to get a single result. *Note Writing GLR Parsers: GLR Parsers. -- Directive: %name-prefix "PREFIX" Obsoleted by the `%define' variable `api.prefix' (*note Multiple Parsers in the Same Program: Multiple Parsers.). Rename the external symbols (variables and functions) used in the parser so that they start with PREFIX instead of `yy'. Contrary to `api.prefix', do no rename types and macros. The precise list of symbols renamed in C parsers is `yyparse', `yylex', `yyerror', `yynerrs', `yylval', `yychar', `yydebug', and (if locations are used) `yylloc'. If you use a push parser, `yypush_parse', `yypull_parse', `yypstate', `yypstate_new' and `yypstate_delete' will also be renamed. For example, if you use `%name-prefix "c_"', the names become `c_parse', `c_lex', and so on. For C++ parsers, see the `%define namespace' documentation in this section. -- Directive: %no-lines Bison declaration to avoid generating `#line' directives in the parser implementation file. *Note Decl Summary::. -- Directive: %nonassoc Bison declaration to assign nonassociativity to token(s). *Note Operator Precedence: Precedence Decl. -- Directive: %output "FILE" Bison declaration to set the name of the parser implementation file. *Note Decl Summary::. -- Directive: %parse-param {ARGUMENT-DECLARATION} Bison declaration to specifying an additional parameter that `yyparse' should accept. *Note The Parser Function `yyparse': Parser Function. -- Directive: %prec Bison declaration to assign a precedence to a specific rule. *Note Context-Dependent Precedence: Contextual Precedence. -- Directive: %pure-parser Deprecated version of `%define api.pure' (*note api.pure: %define Summary.), for which Bison is more careful to warn about unreasonable usage. -- Directive: %require "VERSION" Require version VERSION or higher of Bison. *Note Require a Version of Bison: Require Decl. -- Directive: %right Bison declaration to assign right associativity to token(s). *Note Operator Precedence: Precedence Decl. -- Directive: %skeleton Specify the skeleton to use; usually for development. *Note Decl Summary::. -- Directive: %start Bison declaration to specify the start symbol. *Note The Start-Symbol: Start Decl. -- Directive: %token Bison declaration to declare token(s) without specifying precedence. *Note Token Type Names: Token Decl. -- Directive: %token-table Bison declaration to include a token name table in the parser implementation file. *Note Decl Summary::. -- Directive: %type Bison declaration to declare nonterminals. *Note Nonterminal Symbols: Type Decl. -- Symbol: $undefined The predefined token onto which all undefined values returned by `yylex' are mapped. It cannot be used in the grammar, rather, use `error'. -- Directive: %union Bison declaration to specify several possible data types for semantic values. *Note The Collection of Value Types: Union Decl. -- Macro: YYABORT Macro to pretend that an unrecoverable syntax error has occurred, by making `yyparse' return 1 immediately. The error reporting function `yyerror' is not called. *Note The Parser Function `yyparse': Parser Function. For Java parsers, this functionality is invoked using `return YYABORT;' instead. -- Macro: YYACCEPT Macro to pretend that a complete utterance of the language has been read, by making `yyparse' return 0 immediately. *Note The Parser Function `yyparse': Parser Function. For Java parsers, this functionality is invoked using `return YYACCEPT;' instead. -- Macro: YYBACKUP Macro to discard a value from the parser stack and fake a lookahead token. *Note Special Features for Use in Actions: Action Features. -- Variable: yychar External integer variable that contains the integer value of the lookahead token. (In a pure parser, it is a local variable within `yyparse'.) Error-recovery rule actions may examine this variable. *Note Special Features for Use in Actions: Action Features. -- Variable: yyclearin Macro used in error-recovery rule actions. It clears the previous lookahead token. *Note Error Recovery::. -- Macro: YYDEBUG Macro to define to equip the parser with tracing code. *Note Tracing Your Parser: Tracing. -- Variable: yydebug External integer variable set to zero by default. If `yydebug' is given a nonzero value, the parser will output information on input symbols and parser action. *Note Tracing Your Parser: Tracing. -- Macro: yyerrok Macro to cause parser to recover immediately to its normal mode after a syntax error. *Note Error Recovery::. -- Macro: YYERROR Cause an immediate syntax error. This statement initiates error recovery just as if the parser itself had detected an error; however, it does not call `yyerror', and does not print any message. If you want to print an error message, call `yyerror' explicitly before the `YYERROR;' statement. *Note Error Recovery::. For Java parsers, this functionality is invoked using `return YYERROR;' instead. -- Function: yyerror User-supplied function to be called by `yyparse' on error. *Note The Error Reporting Function `yyerror': Error Reporting. -- Macro: YYERROR_VERBOSE An obsolete macro that you define with `#define' in the prologue to request verbose, specific error message strings when `yyerror' is called. It doesn't matter what definition you use for `YYERROR_VERBOSE', just whether you define it. Supported by the C skeletons only; using `%error-verbose' is preferred. *Note Error Reporting::. -- Macro: YYFPRINTF Macro used to output run-time traces. *Note Enabling Traces::. -- Macro: YYINITDEPTH Macro for specifying the initial size of the parser stack. *Note Memory Management::. -- Function: yylex User-supplied lexical analyzer function, called with no arguments to get the next token. *Note The Lexical Analyzer Function `yylex': Lexical. -- Macro: YYLEX_PARAM An obsolete macro for specifying an extra argument (or list of extra arguments) for `yyparse' to pass to `yylex'. The use of this macro is deprecated, and is supported only for Yacc like parsers. *Note Calling Conventions for Pure Parsers: Pure Calling. -- Variable: yylloc External variable in which `yylex' should place the line and column numbers associated with a token. (In a pure parser, it is a local variable within `yyparse', and its address is passed to `yylex'.) You can ignore this variable if you don't use the `@' feature in the grammar actions. *Note Textual Locations of Tokens: Token Locations. In semantic actions, it stores the location of the lookahead token. *Note Actions and Locations: Actions and Locations. -- Type: YYLTYPE Data type of `yylloc'; by default, a structure with four members. *Note Data Types of Locations: Location Type. -- Variable: yylval External variable in which `yylex' should place the semantic value associated with a token. (In a pure parser, it is a local variable within `yyparse', and its address is passed to `yylex'.) *Note Semantic Values of Tokens: Token Values. In semantic actions, it stores the semantic value of the lookahead token. *Note Actions: Actions. -- Macro: YYMAXDEPTH Macro for specifying the maximum size of the parser stack. *Note Memory Management::. -- Variable: yynerrs Global variable which Bison increments each time it reports a syntax error. (In a pure parser, it is a local variable within `yyparse'. In a pure push parser, it is a member of yypstate.) *Note The Error Reporting Function `yyerror': Error Reporting. -- Function: yyparse The parser function produced by Bison; call this function to start parsing. *Note The Parser Function `yyparse': Parser Function. -- Macro: YYPRINT Macro used to output token semantic values. For `yacc.c' only. Obsoleted by `%printer'. *Note The `YYPRINT' Macro: The YYPRINT Macro. -- Function: yypstate_delete The function to delete a parser instance, produced by Bison in push mode; call this function to delete the memory associated with a parser. *Note The Parser Delete Function `yypstate_delete': Parser Delete Function. (The current push parsing interface is experimental and may evolve. More user feedback will help to stabilize it.) -- Function: yypstate_new The function to create a parser instance, produced by Bison in push mode; call this function to create a new parser. *Note The Parser Create Function `yypstate_new': Parser Create Function. (The current push parsing interface is experimental and may evolve. More user feedback will help to stabilize it.) -- Function: yypull_parse The parser function produced by Bison in push mode; call this function to parse the rest of the input stream. *Note The Pull Parser Function `yypull_parse': Pull Parser Function. (The current push parsing interface is experimental and may evolve. More user feedback will help to stabilize it.) -- Function: yypush_parse The parser function produced by Bison in push mode; call this function to parse a single token. *Note The Push Parser Function `yypush_parse': Push Parser Function. (The current push parsing interface is experimental and may evolve. More user feedback will help to stabilize it.) -- Macro: YYPARSE_PARAM An obsolete macro for specifying the name of a parameter that `yyparse' should accept. The use of this macro is deprecated, and is supported only for Yacc like parsers. *Note Calling Conventions for Pure Parsers: Pure Calling. -- Macro: YYRECOVERING The expression `YYRECOVERING ()' yields 1 when the parser is recovering from a syntax error, and 0 otherwise. *Note Special Features for Use in Actions: Action Features. -- Macro: YYSTACK_USE_ALLOCA Macro used to control the use of `alloca' when the deterministic parser in C needs to extend its stacks. If defined to 0, the parser will use `malloc' to extend its stacks. If defined to 1, the parser will use `alloca'. Values other than 0 and 1 are reserved for future Bison extensions. If not defined, `YYSTACK_USE_ALLOCA' defaults to 0. In the all-too-common case where your code may run on a host with a limited stack and with unreliable stack-overflow checking, you should set `YYMAXDEPTH' to a value that cannot possibly result in unchecked stack overflow on any of your target hosts when `alloca' is called. You can inspect the code that Bison generates in order to determine the proper numeric values. This will require some expertise in low-level implementation details. -- Type: YYSTYPE Data type of semantic values; `int' by default. *Note Data Types of Semantic Values: Value Type.  File: bison.info, Node: Glossary, Next: Copying This Manual, Prev: Table of Symbols, Up: Top Annexe B Glossary ***************** Accepting state A state whose only action is the accept action. The accepting state is thus a consistent state. *Note Understanding::. Backus-Naur Form (BNF; also called "Backus Normal Form") Formal method of specifying context-free grammars originally proposed by John Backus, and slightly improved by Peter Naur in his 1960-01-02 committee document contributing to what became the Algol 60 report. *Note Languages and Context-Free Grammars: Language and Grammar. Consistent state A state containing only one possible action. *Note Default Reductions::. Context-free grammars Grammars specified as rules that can be applied regardless of context. Thus, if there is a rule which says that an integer can be used as an expression, integers are allowed _anywhere_ an expression is permitted. *Note Languages and Context-Free Grammars: Language and Grammar. Default reduction The reduction that a parser should perform if the current parser state contains no other action for the lookahead token. In permitted parser states, Bison declares the reduction with the largest lookahead set to be the default reduction and removes that lookahead set. *Note Default Reductions::. Defaulted state A consistent state with a default reduction. *Note Default Reductions::. Dynamic allocation Allocation of memory that occurs during execution, rather than at compile time or on entry to a function. Empty string Analogous to the empty set in set theory, the empty string is a character string of length zero. Finite-state stack machine A "machine" that has discrete states in which it is said to exist at each instant in time. As input to the machine is processed, the machine moves from state to state as specified by the logic of the machine. In the case of the parser, the input is the language being parsed, and the states correspond to various stages in the grammar rules. *Note The Bison Parser Algorithm: Algorithm. Generalized LR (GLR) A parsing algorithm that can handle all context-free grammars, including those that are not LR(1). It resolves situations that Bison's deterministic parsing algorithm cannot by effectively splitting off multiple parsers, trying all possible parsers, and discarding those that fail in the light of additional right context. *Note Generalized LR Parsing: Generalized LR Parsing. Grouping A language construct that is (in general) grammatically divisible; for example, `expression' or `declaration' in C. *Note Languages and Context-Free Grammars: Language and Grammar. IELR(1) (Inadequacy Elimination LR(1)) A minimal LR(1) parser table construction algorithm. That is, given any context-free grammar, IELR(1) generates parser tables with the full language-recognition power of canonical LR(1) but with nearly the same number of parser states as LALR(1). This reduction in parser states is often an order of magnitude. More importantly, because canonical LR(1)'s extra parser states may contain duplicate conflicts in the case of non-LR(1) grammars, the number of conflicts for IELR(1) is often an order of magnitude less as well. This can significantly reduce the complexity of developing a grammar. *Note LR Table Construction::. Infix operator An arithmetic operator that is placed between the operands on which it performs some operation. Input stream A continuous flow of data between devices or programs. LAC (Lookahead Correction) A parsing mechanism that fixes the problem of delayed syntax error detection, which is caused by LR state merging, default reductions, and the use of `%nonassoc'. Delayed syntax error detection results in unexpected semantic actions, initiation of error recovery in the wrong syntactic context, and an incorrect list of expected tokens in a verbose syntax error message. *Note LAC::. Language construct One of the typical usage schemas of the language. For example, one of the constructs of the C language is the `if' statement. *Note Languages and Context-Free Grammars: Language and Grammar. Left associativity Operators having left associativity are analyzed from left to right: `a+b+c' first computes `a+b' and then combines with `c'. *Note Operator Precedence: Precedence. Left recursion A rule whose result symbol is also its first component symbol; for example, `expseq1 : expseq1 ',' exp;'. *Note Recursive Rules: Recursion. Left-to-right parsing Parsing a sentence of a language by analyzing it token by token from left to right. *Note The Bison Parser Algorithm: Algorithm. Lexical analyzer (scanner) A function that reads an input stream and returns tokens one by one. *Note The Lexical Analyzer Function `yylex': Lexical. Lexical tie-in A flag, set by actions in the grammar rules, which alters the way tokens are parsed. *Note Lexical Tie-ins::. Literal string token A token which consists of two or more fixed characters. *Note Symbols::. Lookahead token A token already read but not yet shifted. *Note Lookahead Tokens: Lookahead. LALR(1) The class of context-free grammars that Bison (like most other parser generators) can handle by default; a subset of LR(1). *Note Mysterious Conflicts::. LR(1) The class of context-free grammars in which at most one token of lookahead is needed to disambiguate the parsing of any piece of input. Nonterminal symbol A grammar symbol standing for a grammatical construct that can be expressed through rules in terms of smaller constructs; in other words, a construct that is not a token. *Note Symbols::. Parser A function that recognizes valid sentences of a language by analyzing the syntax structure of a set of tokens passed to it from a lexical analyzer. Postfix operator An arithmetic operator that is placed after the operands upon which it performs some operation. Reduction Replacing a string of nonterminals and/or terminals with a single nonterminal, according to a grammar rule. *Note The Bison Parser Algorithm: Algorithm. Reentrant A reentrant subprogram is a subprogram which can be in invoked any number of times in parallel, without interference between the various invocations. *Note A Pure (Reentrant) Parser: Pure Decl. Reverse polish notation A language in which all operators are postfix operators. Right recursion A rule whose result symbol is also its last component symbol; for example, `expseq1: exp ',' expseq1;'. *Note Recursive Rules: Recursion. Semantics In computer languages, the semantics are specified by the actions taken for each instance of the language, i.e., the meaning of each statement. *Note Defining Language Semantics: Semantics. Shift A parser is said to shift when it makes the choice of analyzing further input from the stream rather than reducing immediately some already-recognized rule. *Note The Bison Parser Algorithm: Algorithm. Single-character literal A single character that is recognized and interpreted as is. *Note From Formal Rules to Bison Input: Grammar in Bison. Start symbol The nonterminal symbol that stands for a complete valid utterance in the language being parsed. The start symbol is usually listed as the first nonterminal symbol in a language specification. *Note The Start-Symbol: Start Decl. Symbol table A data structure where symbol names and associated data are stored during parsing to allow for recognition and use of existing information in repeated uses of a symbol. *Note Multi-function Calc::. Syntax error An error encountered during parsing of an input stream due to invalid syntax. *Note Error Recovery::. Token A basic, grammatically indivisible unit of a language. The symbol that describes a token in the grammar is a terminal symbol. The input of the Bison parser is a stream of tokens which comes from the lexical analyzer. *Note Symbols::. Terminal symbol A grammar symbol that has no rules in the grammar and therefore is grammatically indivisible. The piece of text it represents is a token. *Note Languages and Context-Free Grammars: Language and Grammar. Unreachable state A parser state to which there does not exist a sequence of transitions from the parser's start state. A state can become unreachable during conflict resolution. *Note Unreachable States::.  File: bison.info, Node: Copying This Manual, Next: Bibliography, Prev: Glossary, Up: Top Annexe C Copying This Manual **************************** Version 1.3, 3 November 2008 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. `http://fsf.org/' Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. The "publisher" means any person or entity that distributes copies of the Document to the public. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements." 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License. However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See `http://www.gnu.org/copyleft/'. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Document. 11. RELICENSING "Massive Multiauthor Collaboration Site" (or "MMC Site") means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A "Massive Multiauthor Collaboration" (or "MMC") contained in the site means any set of copyrightable works thus published on the MMC site. "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization. "Incorporate" means to publish or republish a Document, in whole or in part, as part of another Document. An MMC is "eligible for relicensing" if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008. The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing. ADDENDUM: How to use this License for your documents ==================================================== To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright (C) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''. If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this: with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.  File: bison.info, Node: Bibliography, Next: Index of Terms, Prev: Copying This Manual, Up: Top Bibliography ************ [Denny 2008] Joel E. Denny and Brian A. Malloy, IELR(1): Practical LR(1) Parser Tables for Non-LR(1) Grammars with Conflict Resolution, in `Proceedings of the 2008 ACM Symposium on Applied Computing' (SAC'08), ACM, New York, NY, USA, pp. 240-245. `http://dx.doi.org/10.1145/1363686.1363747' [Denny 2010 May] Joel E. Denny, PSLR(1): Pseudo-Scannerless Minimal LR(1) for the Deterministic Parsing of Composite Languages, Ph.D. Dissertation, Clemson University, Clemson, SC, USA (May 2010). `http://proquest.umi.com/pqdlink?did=2041473591&Fmt=7&clientId=79356&RQT=309&VName=PQD' [Denny 2010 November] Joel E. Denny and Brian A. Malloy, The IELR(1) Algorithm for Generating Minimal LR(1) Parser Tables for Non-LR(1) Grammars with Conflict Resolution, in `Science of Computer Programming', Vol. 75, Issue 11 (November 2010), pp. 943-979. `http://dx.doi.org/10.1016/j.scico.2009.08.001' [DeRemer 1982] Frank DeRemer and Thomas Pennello, Efficient Computation of LALR(1) Look-Ahead Sets, in `ACM Transactions on Programming Languages and Systems', Vol. 4, No. 4 (October 1982), pp. 615-649. `http://dx.doi.org/10.1145/69622.357187' [Knuth 1965] Donald E. Knuth, On the Translation of Languages from Left to Right, in `Information and Control', Vol. 8, Issue 6 (December 1965), pp. 607-639. `http://dx.doi.org/10.1016/S0019-9958(65)90426-2' [Scott 2000] Elizabeth Scott, Adrian Johnstone, and Shamsa Sadaf Hussain, `Tomita-Style Generalised LR Parsers', Royal Holloway, University of London, Department of Computer Science, TR-00-12 (December 2000). `http://www.cs.rhul.ac.uk/research/languages/publications/tomita_style_1.ps'  File: bison.info, Node: Index of Terms, Prev: Bibliography, Up: Top Index of Terms ************** [index] * Menu: * $ <1>: Action Features. (line 14) * $ <2>: Table of Symbols. (line 31) * $ <3>: Java Action Features. (line 13) * $: Table of Symbols. (line 35) * $$ <1>: Java Action Features. (line 21) * $$ <2>: Actions. (line 6) * $$ <3>: Action Features. (line 10) * $$: Table of Symbols. (line 23) * $< <1>: Action Features. (line 23) * $<: Java Action Features. (line 17) * $[NAME]: Actions. (line 6) * $accept: Table of Symbols. (line 81) * $end: Table of Symbols. (line 119) * $N: Actions. (line 6) * $NAME: Actions. (line 6) * $undefined: Table of Symbols. (line 240) * % <1>: Table of Symbols. (line 44) * %: Java Declarations Summary. (line 53) * %% <1>: Table of Symbols. (line 39) * %%: Java Declarations Summary. (line 49) * %code <1>: Decl Summary. (line 47) * %code <2>: Java Declarations Summary. (line 37) * %code <3>: %code Summary. (line 6) * %code <4>: Prologue Alternatives. (line 6) * %code <5>: Table of Symbols. (line 86) * %code <6>: %code Summary. (line 27) * %code <7>: Table of Symbols. (line 87) * %code: Calc++ Parser. (line 65) * %code imports <1>: Java Declarations Summary. (line 41) * %code imports: %code Summary. (line 83) * %code lexer: Java Declarations Summary. (line 45) * %code provides <1>: Decl Summary. (line 95) * %code provides <2>: %code Summary. (line 55) * %code provides: Prologue Alternatives. (line 6) * %code requires <1>: Prologue Alternatives. (line 6) * %code requires <2>: Decl Summary. (line 95) * %code requires <3>: %code Summary. (line 41) * %code requires: Calc++ Parser. (line 17) * %code top <1>: Prologue Alternatives. (line 6) * %code top: %code Summary. (line 67) * %debug <1>: Table of Symbols. (line 92) * %debug <2>: Enabling Traces. (line 28) * %debug: Decl Summary. (line 52) * %define <1>: Decl Summary. (line 61) * %define <2>: %define Summary. (line 15) * %define <3>: Decl Summary. (line 59) * %define <4>: Table of Symbols. (line 95) * %define: %define Summary. (line 14) * %define abstract: Java Declarations Summary. (line 57) * %define api.prefix: %define Summary. (line 49) * %define api.pure <1>: %define Summary. (line 62) * %define api.pure: Pure Decl. (line 6) * %define api.push-pull <1>: Push Decl. (line 6) * %define api.push-pull: %define Summary. (line 73) * %define extends: Java Declarations Summary. (line 61) * %define final: Java Declarations Summary. (line 65) * %define implements: Java Declarations Summary. (line 69) * %define lex_throws: Java Declarations Summary. (line 73) * %define location_type: Java Declarations Summary. (line 78) * %define lr.default-reductions <1>: Default Reductions. (line 6) * %define lr.default-reductions: %define Summary. (line 86) * %define lr.default-reductions WHERE: Default Reductions. (line 84) * %define lr.keep-unreachable-states <1>: %define Summary. (line 103) * %define lr.keep-unreachable-states: Unreachable States. (line 6) * %define lr.keep-unreachable-states VALUE: Unreachable States. (line 17) * %define lr.type <1>: %define Summary. (line 114) * %define lr.type: LR Table Construction. (line 6) * %define lr.type TYPE: LR Table Construction. (line 24) * %define namespace <1>: %define Summary. (line 126) * %define namespace: C++ Bison Interface. (line 10) * %define package: Java Declarations Summary. (line 84) * %define parse.lac <1>: LAC. (line 6) * %define parse.lac: %define Summary. (line 166) * %define parse.lac VALUE: LAC. (line 29) * %define parser_class_name: Java Declarations Summary. (line 88) * %define position_type: Java Declarations Summary. (line 92) * %define public: Java Declarations Summary. (line 97) * %define strictfp: Java Declarations Summary. (line 105) * %define stype: Java Declarations Summary. (line 101) * %define throws: Java Declarations Summary. (line 109) * %defines <1>: Decl Summary. (line 65) * %defines: Table of Symbols. (line 101) * %destructor <1>: Table of Symbols. (line 109) * %destructor <2>: Decl Summary. (line 102) * %destructor <3>: Destructor Decl. (line 6) * %destructor: Mid-Rule Actions. (line 59) * %dprec <1>: Merging GLR Parses. (line 6) * %dprec: Table of Symbols. (line 114) * %error-verbose <1>: Error Reporting. (line 17) * %error-verbose: Table of Symbols. (line 133) * %expect <1>: Decl Summary. (line 38) * %expect: Expect Decl. (line 6) * %expect-rr <1>: Expect Decl. (line 6) * %expect-rr: Simple GLR Parsers. (line 6) * %file-prefix <1>: Table of Symbols. (line 137) * %file-prefix: Decl Summary. (line 107) * %glr-parser <1>: Simple GLR Parsers. (line 6) * %glr-parser <2>: Table of Symbols. (line 141) * %glr-parser: GLR Parsers. (line 6) * %initial-action <1>: Table of Symbols. (line 145) * %initial-action: Initial Action Decl. (line 11) * %language <1>: Table of Symbols. (line 149) * %language: Decl Summary. (line 111) * %language "Java": Java Declarations Summary. (line 10) * %left <1>: Table of Symbols. (line 153) * %left <2>: Using Precedence. (line 6) * %left: Decl Summary. (line 21) * %lex-param <1>: Table of Symbols. (line 157) * %lex-param <2>: Java Declarations Summary. (line 13) * %lex-param: Pure Calling. (line 31) * %locations: Decl Summary. (line 119) * %merge <1>: Merging GLR Parses. (line 6) * %merge: Table of Symbols. (line 162) * %name-prefix <1>: Java Declarations Summary. (line 19) * %name-prefix: Table of Symbols. (line 169) * %no-lines <1>: Table of Symbols. (line 186) * %no-lines: Decl Summary. (line 126) * %nonassoc <1>: Decl Summary. (line 25) * %nonassoc <2>: Table of Symbols. (line 190) * %nonassoc <3>: Default Reductions. (line 6) * %nonassoc <4>: LR Table Construction. (line 103) * %nonassoc: Using Precedence. (line 6) * %output <1>: Table of Symbols. (line 194) * %output: Decl Summary. (line 135) * %parse-param <1>: Parser Function. (line 36) * %parse-param <2>: Java Declarations Summary. (line 24) * %parse-param <3>: Parser Function. (line 36) * %parse-param: Table of Symbols. (line 198) * %prec <1>: Contextual Precedence. (line 6) * %prec: Table of Symbols. (line 203) * %printer: Printer Decl. (line 6) * %pure-parser <1>: Table of Symbols. (line 207) * %pure-parser: Decl Summary. (line 138) * %require <1>: Require Decl. (line 6) * %require <2>: Decl Summary. (line 143) * %require: Table of Symbols. (line 212) * %right <1>: Using Precedence. (line 6) * %right <2>: Table of Symbols. (line 216) * %right: Decl Summary. (line 17) * %skeleton <1>: Table of Symbols. (line 220) * %skeleton: Decl Summary. (line 147) * %start <1>: Start Decl. (line 6) * %start <2>: Decl Summary. (line 34) * %start: Table of Symbols. (line 224) * %token <1>: Decl Summary. (line 13) * %token <2>: Java Declarations Summary. (line 29) * %token <3>: Table of Symbols. (line 228) * %token: Token Decl. (line 6) * %token-table <1>: Decl Summary. (line 155) * %token-table: Table of Symbols. (line 232) * %type <1>: Type Decl. (line 6) * %type <2>: Table of Symbols. (line 236) * %type <3>: Decl Summary. (line 30) * %type: Java Declarations Summary. (line 33) * %union <1>: Decl Summary. (line 9) * %union <2>: Union Decl. (line 6) * %union: Table of Symbols. (line 245) * %verbose: Decl Summary. (line 188) * %yacc: Decl Summary. (line 194) * /*: Table of Symbols. (line 49) * :: Table of Symbols. (line 52) * ;: Table of Symbols. (line 56) * <*> <1>: Printer Decl. (line 6) * <*> <2>: Table of Symbols. (line 63) * <*>: Destructor Decl. (line 6) * <> <1>: Printer Decl. (line 6) * <> <2>: Table of Symbols. (line 72) * <>: Destructor Decl. (line 6) * @$ <1>: Table of Symbols. (line 7) * @$ <2>: Actions and Locations. (line 6) * @$ <3>: Action Features. (line 98) * @$: Java Action Features. (line 39) * @[: Table of Symbols. (line 19) * @[NAME]: Actions and Locations. (line 6) * @N <1>: Action Features. (line 104) * @N <2>: Actions and Locations. (line 6) * @N <3>: Java Action Features. (line 35) * @N: Table of Symbols. (line 11) * @NAME <1>: Actions and Locations. (line 6) * @NAME: Table of Symbols. (line 15) * abstract syntax tree: Implementing Gotos/Loops. (line 17) * accepting state: Understanding. (line 178) * action: Actions. (line 6) * action data types: Action Types. (line 6) * action features summary: Action Features. (line 6) * actions in mid-rule <1>: Destructor Decl. (line 88) * actions in mid-rule: Mid-Rule Actions. (line 6) * actions, location: Actions and Locations. (line 6) * actions, semantic: Semantic Actions. (line 6) * additional C code section: Epilogue. (line 6) * algorithm of parser: Algorithm. (line 6) * ambiguous grammars <1>: Generalized LR Parsing. (line 6) * ambiguous grammars: Language and Grammar. (line 34) * associativity: Why Precedence. (line 34) * AST: Implementing Gotos/Loops. (line 17) * Backus-Naur form: Language and Grammar. (line 16) * begin of Location: Java Location Values. (line 21) * begin of location: C++ location. (line 22) * Bison declaration summary: Decl Summary. (line 6) * Bison declarations: Declarations. (line 6) * Bison declarations (introduction): Bison Declarations. (line 6) * Bison grammar: Grammar in Bison. (line 6) * Bison invocation: Invocation. (line 6) * Bison parser: Bison Parser. (line 6) * Bison parser algorithm: Algorithm. (line 6) * Bison symbols, table of: Table of Symbols. (line 6) * Bison utility: Bison Parser. (line 6) * bison-i18n.m4: Internationalization. (line 20) * bison-po: Internationalization. (line 6) * BISON_I18N: Internationalization. (line 27) * BISON_LOCALEDIR: Internationalization. (line 27) * BNF: Language and Grammar. (line 16) * braced code: Rules. (line 29) * C code, section for additional: Epilogue. (line 6) * C-language interface: Interface. (line 6) * calc: Infix Calc. (line 6) * calculator, infix notation: Infix Calc. (line 6) * calculator, location tracking: Location Tracking Calc. (line 6) * calculator, multi-function: Multi-function Calc. (line 6) * calculator, simple: RPN Calc. (line 6) * canonical LR <1>: Mysterious Conflicts. (line 45) * canonical LR: LR Table Construction. (line 6) * character token: Symbols. (line 37) * column of position: C++ position. (line 29) * columns on location: C++ location. (line 26) * columns on position: C++ position. (line 32) * compiling the parser: Rpcalc Compile. (line 6) * conflicts <1>: Shift/Reduce. (line 6) * conflicts <2>: Merging GLR Parses. (line 6) * conflicts <3>: Simple GLR Parsers. (line 6) * conflicts: GLR Parsers. (line 6) * conflicts, reduce/reduce: Reduce/Reduce. (line 6) * conflicts, suppressing warnings of: Expect Decl. (line 6) * consistent states: Default Reductions. (line 17) * context-dependent precedence: Contextual Precedence. (line 6) * context-free grammar: Language and Grammar. (line 6) * controlling function: Rpcalc Main. (line 6) * core, item set: Understanding. (line 125) * dangling else: Shift/Reduce. (line 6) * data type of locations: Location Type. (line 6) * data types in actions: Action Types. (line 6) * data types of semantic values: Value Type. (line 6) * debug_level on parser: C++ Parser Interface. (line 38) * debug_stream on parser: C++ Parser Interface. (line 33) * debugging: Tracing. (line 6) * declaration summary: Decl Summary. (line 6) * declarations: Prologue. (line 6) * declarations section: Prologue. (line 6) * declarations, Bison: Declarations. (line 6) * declarations, Bison (introduction): Bison Declarations. (line 6) * declaring literal string tokens: Token Decl. (line 6) * declaring operator precedence: Precedence Decl. (line 6) * declaring the start symbol: Start Decl. (line 6) * declaring token type names: Token Decl. (line 6) * declaring value types: Union Decl. (line 6) * declaring value types, nonterminals: Type Decl. (line 6) * default action: Actions. (line 62) * default data type: Value Type. (line 6) * default location type: Location Type. (line 6) * default reductions: Default Reductions. (line 6) * default stack limit: Memory Management. (line 30) * default start symbol: Start Decl. (line 6) * defaulted states: Default Reductions. (line 17) * deferred semantic actions: GLR Semantic Actions. (line 6) * defining language semantics: Semantics. (line 6) * delayed syntax error detection <1>: LR Table Construction. (line 103) * delayed syntax error detection: Default Reductions. (line 43) * delayed yylex invocations: Default Reductions. (line 17) * discarded symbols: Destructor Decl. (line 98) * discarded symbols, mid-rule actions: Mid-Rule Actions. (line 59) * else, dangling: Shift/Reduce. (line 6) * end of location: C++ location. (line 23) * end of Location: Java Location Values. (line 22) * epilogue: Epilogue. (line 6) * error <1>: Error Recovery. (line 20) * error: Table of Symbols. (line 123) * error on parser: C++ Parser Interface. (line 44) * error recovery: Error Recovery. (line 6) * error recovery, mid-rule actions: Mid-Rule Actions. (line 59) * error recovery, simple: Simple Error Recovery. (line 6) * error reporting function: Error Reporting. (line 6) * error reporting routine: Rpcalc Error. (line 6) * examples, simple: Examples. (line 6) * exercises: Exercises. (line 6) * file format: Grammar Layout. (line 6) * file of position: C++ position. (line 17) * finite-state machine: Parser States. (line 6) * formal grammar: Grammar in Bison. (line 6) * format of grammar file: Grammar Layout. (line 6) * freeing discarded symbols: Destructor Decl. (line 6) * frequently asked questions: FAQ. (line 6) * generalized LR (GLR) parsing <1>: Language and Grammar. (line 34) * generalized LR (GLR) parsing <2>: GLR Parsers. (line 6) * generalized LR (GLR) parsing: Generalized LR Parsing. (line 6) * generalized LR (GLR) parsing, ambiguous grammars: Merging GLR Parses. (line 6) * generalized LR (GLR) parsing, unambiguous grammars: Simple GLR Parsers. (line 6) * getDebugLevel on YYParser: Java Parser Interface. (line 67) * getDebugStream on YYParser: Java Parser Interface. (line 62) * getEndPos on Lexer: Java Scanner Interface. (line 39) * getLVal on Lexer: Java Scanner Interface. (line 47) * getStartPos on Lexer: Java Scanner Interface. (line 38) * gettext: Internationalization. (line 6) * glossary: Glossary. (line 6) * GLR parsers and inline: Compiler Requirements. (line 6) * GLR parsers and yychar: GLR Semantic Actions. (line 10) * GLR parsers and yyclearin: GLR Semantic Actions. (line 18) * GLR parsers and YYERROR: GLR Semantic Actions. (line 28) * GLR parsers and yylloc: GLR Semantic Actions. (line 10) * GLR parsers and YYLLOC_DEFAULT: Location Default Action. (line 6) * GLR parsers and yylval: GLR Semantic Actions. (line 10) * GLR parsing <1>: Generalized LR Parsing. (line 6) * GLR parsing <2>: GLR Parsers. (line 6) * GLR parsing: Language and Grammar. (line 34) * GLR parsing, ambiguous grammars: Merging GLR Parses. (line 6) * GLR parsing, unambiguous grammars: Simple GLR Parsers. (line 6) * GLR with LALR: LR Table Construction. (line 65) * grammar file: Grammar Layout. (line 6) * grammar rule syntax: Rules. (line 6) * grammar rules section: Grammar Rules. (line 6) * grammar, Bison: Grammar in Bison. (line 6) * grammar, context-free: Language and Grammar. (line 6) * grouping, syntactic: Language and Grammar. (line 48) * i18n: Internationalization. (line 6) * IELR <1>: LR Table Construction. (line 6) * IELR: Mysterious Conflicts. (line 45) * IELR grammars: Language and Grammar. (line 22) * infix notation calculator: Infix Calc. (line 6) * initialize on location: C++ location. (line 19) * initialize on position: C++ position. (line 14) * inline: Compiler Requirements. (line 6) * interface: Interface. (line 6) * internationalization: Internationalization. (line 6) * introduction: Introduction. (line 6) * invoking Bison: Invocation. (line 6) * item: Understanding. (line 103) * item set core: Understanding. (line 125) * kernel, item set: Understanding. (line 125) * LAC <1>: LR Table Construction. (line 103) * LAC <2>: Default Reductions. (line 54) * LAC: LAC. (line 6) * LALR <1>: Mysterious Conflicts. (line 33) * LALR: LR Table Construction. (line 6) * LALR grammars: Language and Grammar. (line 22) * language semantics, defining: Semantics. (line 6) * layout of Bison grammar: Grammar Layout. (line 6) * left recursion: Recursion. (line 17) * lex-param: Pure Calling. (line 31) * lexical analyzer: Lexical. (line 6) * lexical analyzer, purpose: Bison Parser. (line 6) * lexical analyzer, writing: Rpcalc Lexer. (line 6) * lexical tie-in: Lexical Tie-ins. (line 6) * line of position: C++ position. (line 23) * lines on location: C++ location. (line 27) * lines on position: C++ position. (line 26) * literal string token: Symbols. (line 59) * literal token: Symbols. (line 37) * location <1>: Tracking Locations. (line 6) * location: Locations. (line 6) * location actions: Actions and Locations. (line 6) * Location on Location: Java Location Values. (line 29) * location on location: C++ location. (line 8) * Location on Location: Java Location Values. (line 25) * location tracking calculator: Location Tracking Calc. (line 6) * location, textual <1>: Locations. (line 6) * location, textual: Tracking Locations. (line 6) * location_type: C++ Parser Interface. (line 16) * lookahead correction: LAC. (line 6) * lookahead token: Lookahead. (line 6) * LR: Mysterious Conflicts. (line 33) * LR grammars: Language and Grammar. (line 22) * ltcalc: Location Tracking Calc. (line 6) * main function in simple example: Rpcalc Main. (line 6) * memory exhaustion: Memory Management. (line 6) * memory management: Memory Management. (line 6) * mfcalc: Multi-function Calc. (line 6) * mid-rule actions <1>: Mid-Rule Actions. (line 6) * mid-rule actions: Destructor Decl. (line 88) * multi-function calculator: Multi-function Calc. (line 6) * multicharacter literal: Symbols. (line 59) * mutual recursion: Recursion. (line 34) * Mysterious Conflict: LR Table Construction. (line 6) * Mysterious Conflicts: Mysterious Conflicts. (line 6) * named references: Named References. (line 6) * NLS: Internationalization. (line 6) * nondeterministic parsing <1>: Generalized LR Parsing. (line 6) * nondeterministic parsing: Language and Grammar. (line 34) * nonterminal symbol: Symbols. (line 6) * nonterminal, useless: Understanding. (line 49) * operator precedence: Precedence. (line 6) * operator precedence, declaring: Precedence Decl. (line 6) * operator!= on location: C++ location. (line 39) * operator!= on position: C++ position. (line 42) * operator+ on location: C++ location. (line 30) * operator+ on position: C++ position. (line 36) * operator+= on location: C++ location. (line 32) * operator+= on position: C++ position. (line 35) * operator- on position: C++ position. (line 38) * operator-= on position: C++ position. (line 37) * operator<< <1>: C++ position. (line 46) * operator<<: C++ location. (line 44) * operator== on location: C++ location. (line 38) * operator== on position: C++ position. (line 41) * options for invoking Bison: Invocation. (line 6) * overflow of parser stack: Memory Management. (line 6) * parse error: Error Reporting. (line 6) * parse on parser: C++ Parser Interface. (line 30) * parse on YYParser: Java Parser Interface. (line 54) * parser: Bison Parser. (line 6) * parser on parser: C++ Parser Interface. (line 26) * parser stack: Algorithm. (line 6) * parser stack overflow: Memory Management. (line 6) * parser state: Parser States. (line 6) * pointed rule: Understanding. (line 103) * polish notation calculator: RPN Calc. (line 6) * position on position: C++ position. (line 8) * precedence declarations: Precedence Decl. (line 6) * precedence of operators: Precedence. (line 6) * precedence, context-dependent: Contextual Precedence. (line 6) * precedence, unary operator: Contextual Precedence. (line 6) * preventing warnings about conflicts: Expect Decl. (line 6) * printing semantic values: Printer Decl. (line 6) * Prologue <1>: Prologue. (line 6) * Prologue: %code Summary. (line 6) * Prologue Alternatives: Prologue Alternatives. (line 6) * pure parser: Pure Decl. (line 6) * push parser: Push Decl. (line 6) * questions: FAQ. (line 6) * recovering: Java Action Features. (line 55) * recovering on YYParser: Java Parser Interface. (line 58) * recovery from errors: Error Recovery. (line 6) * recursive rule: Recursion. (line 6) * reduce/reduce conflict: Reduce/Reduce. (line 6) * reduce/reduce conflicts <1>: Merging GLR Parses. (line 6) * reduce/reduce conflicts <2>: GLR Parsers. (line 6) * reduce/reduce conflicts: Simple GLR Parsers. (line 6) * reduction: Algorithm. (line 6) * reentrant parser: Pure Decl. (line 6) * requiring a version of Bison: Require Decl. (line 6) * reverse polish notation: RPN Calc. (line 6) * right recursion: Recursion. (line 17) * rpcalc: RPN Calc. (line 6) * rule syntax: Rules. (line 6) * rule, pointed: Understanding. (line 103) * rule, useless: Understanding. (line 49) * rules section for grammar: Grammar Rules. (line 6) * running Bison (introduction): Rpcalc Generate. (line 6) * semantic actions: Semantic Actions. (line 6) * semantic value: Semantic Values. (line 6) * semantic value type: Value Type. (line 6) * semantic_type: C++ Parser Interface. (line 15) * set_debug_level on parser: C++ Parser Interface. (line 39) * set_debug_stream on parser: C++ Parser Interface. (line 34) * setDebugLevel on YYParser: Java Parser Interface. (line 68) * setDebugStream on YYParser: Java Parser Interface. (line 63) * shift/reduce conflicts <1>: Shift/Reduce. (line 6) * shift/reduce conflicts <2>: Simple GLR Parsers. (line 6) * shift/reduce conflicts: GLR Parsers. (line 6) * shifting: Algorithm. (line 6) * simple examples: Examples. (line 6) * single-character literal: Symbols. (line 37) * stack overflow: Memory Management. (line 6) * stack, parser: Algorithm. (line 6) * stages in using Bison: Stages. (line 6) * start symbol: Language and Grammar. (line 97) * start symbol, declaring: Start Decl. (line 6) * state (of parser): Parser States. (line 6) * step on location: C++ location. (line 35) * string token: Symbols. (line 59) * summary, action features: Action Features. (line 6) * summary, Bison declaration: Decl Summary. (line 6) * suppressing conflict warnings: Expect Decl. (line 6) * symbol: Symbols. (line 6) * symbol table example: Mfcalc Symbol Table. (line 6) * symbols (abstract): Language and Grammar. (line 48) * symbols in Bison, table of: Table of Symbols. (line 6) * syntactic grouping: Language and Grammar. (line 48) * syntax error: Error Reporting. (line 6) * syntax of grammar rules: Rules. (line 6) * terminal symbol: Symbols. (line 6) * textual location <1>: Tracking Locations. (line 6) * textual location: Locations. (line 6) * token <1>: Language and Grammar. (line 48) * token: C++ Parser Interface. (line 19) * token type: Symbols. (line 6) * token type names, declaring: Token Decl. (line 6) * token, useless: Understanding. (line 49) * toString on Location: Java Location Values. (line 32) * tracing the parser: Tracing. (line 6) * uint: C++ Location Values. (line 12) * unary operator precedence: Contextual Precedence. (line 6) * unreachable states: Unreachable States. (line 6) * useless nonterminal: Understanding. (line 49) * useless rule: Understanding. (line 49) * useless token: Understanding. (line 49) * using Bison: Stages. (line 6) * value type, semantic: Value Type. (line 6) * value types, declaring: Union Decl. (line 6) * value types, nonterminals, declaring: Type Decl. (line 6) * value, semantic: Semantic Values. (line 6) * version requirement: Require Decl. (line 6) * warnings, preventing: Expect Decl. (line 6) * writing a lexical analyzer: Rpcalc Lexer. (line 6) * YYABORT <1>: Java Action Features. (line 43) * YYABORT <2>: Parser Function. (line 29) * YYABORT <3>: Table of Symbols. (line 249) * YYABORT: Action Features. (line 28) * YYACCEPT <1>: Action Features. (line 32) * YYACCEPT <2>: Java Action Features. (line 47) * YYACCEPT <3>: Table of Symbols. (line 258) * YYACCEPT: Parser Function. (line 26) * YYBACKUP <1>: Table of Symbols. (line 266) * YYBACKUP: Action Features. (line 36) * yychar <1>: Table of Symbols. (line 270) * yychar <2>: Lookahead. (line 49) * yychar <3>: Action Features. (line 69) * yychar: GLR Semantic Actions. (line 10) * yyclearin <1>: Table of Symbols. (line 276) * yyclearin <2>: Error Recovery. (line 99) * yyclearin <3>: GLR Semantic Actions. (line 18) * yyclearin: Action Features. (line 76) * YYDEBUG: Table of Symbols. (line 280) * yydebug <1>: Table of Symbols. (line 284) * yydebug: Tracing. (line 6) * YYDEBUG: Enabling Traces. (line 9) * YYEMPTY: Action Features. (line 49) * YYENABLE_NLS: Internationalization. (line 27) * YYEOF: Action Features. (line 52) * yyerrok <1>: Error Recovery. (line 94) * yyerrok <2>: Action Features. (line 81) * yyerrok: Table of Symbols. (line 289) * yyerror: Java Action Features. (line 61) * YYERROR: Java Action Features. (line 51) * yyerror: Java Action Features. (line 62) * YYERROR: Table of Symbols. (line 293) * yyerror: Table of Symbols. (line 304) * YYERROR <1>: GLR Semantic Actions. (line 28) * YYERROR: Action Features. (line 56) * yyerror: Error Reporting. (line 6) * yyerror on Lexer: Java Scanner Interface. (line 25) * YYERROR_VERBOSE: Table of Symbols. (line 308) * YYFPRINTF <1>: Table of Symbols. (line 316) * YYFPRINTF: Enabling Traces. (line 36) * YYINITDEPTH <1>: Memory Management. (line 32) * YYINITDEPTH: Table of Symbols. (line 319) * yylex <1>: Table of Symbols. (line 323) * yylex: Lexical. (line 6) * yylex on Lexer: Java Scanner Interface. (line 30) * yylex on parser: C++ Scanner Interface. (line 12) * YYLEX_PARAM: Table of Symbols. (line 328) * yylloc <1>: GLR Semantic Actions. (line 10) * yylloc <2>: Table of Symbols. (line 334) * yylloc <3>: Action Features. (line 86) * yylloc <4>: Actions and Locations. (line 67) * yylloc <5>: Token Locations. (line 6) * yylloc: Lookahead. (line 49) * YYLLOC_DEFAULT: Location Default Action. (line 6) * YYLTYPE <1>: Table of Symbols. (line 344) * YYLTYPE: Token Locations. (line 19) * yylval <1>: Lookahead. (line 49) * yylval <2>: Token Values. (line 6) * yylval <3>: GLR Semantic Actions. (line 10) * yylval <4>: Actions. (line 87) * yylval <5>: Table of Symbols. (line 348) * yylval: Action Features. (line 92) * YYMAXDEPTH <1>: Table of Symbols. (line 356) * YYMAXDEPTH: Memory Management. (line 14) * yynerrs <1>: Error Reporting. (line 94) * yynerrs: Table of Symbols. (line 360) * yyoutput: Printer Decl. (line 16) * yyparse <1>: Parser Function. (line 6) * yyparse <2>: Table of Symbols. (line 366) * yyparse: Parser Function. (line 13) * YYPARSE_PARAM: Table of Symbols. (line 404) * YYParser on YYParser: Java Parser Interface. (line 46) * YYPRINT <1>: Table of Symbols. (line 370) * YYPRINT: The YYPRINT Macro. (line 11) * yypstate_delete <1>: Parser Delete Function. (line 15) * yypstate_delete: Table of Symbols. (line 375) * yypstate_new <1>: Table of Symbols. (line 383) * yypstate_new: Parser Create Function. (line 6) * yypull_parse <1>: Table of Symbols. (line 390) * yypull_parse: Pull Parser Function. (line 14) * yypush_parse <1>: Push Parser Function. (line 15) * yypush_parse <2>: Table of Symbols. (line 397) * yypush_parse: Push Parser Function. (line 6) * YYRECOVERING <1>: Table of Symbols. (line 410) * YYRECOVERING <2>: Error Recovery. (line 111) * YYRECOVERING: Action Features. (line 64) * YYSTACK_USE_ALLOCA: Table of Symbols. (line 415) * YYSTYPE: Table of Symbols. (line 431) * | <1>: Table of Symbols. (line 59) * |: Rules. (line 48)