X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/d5796688b17857ba9041aa65c67f5c2c1c88c3bc..73975f004cc9e9875a10e5135068ac9281ea46bc:/doc/bison.texinfo diff --git a/doc/bison.texinfo b/doc/bison.texinfo index 5ec63108..29ce7b69 100644 --- a/doc/bison.texinfo +++ b/doc/bison.texinfo @@ -318,7 +318,7 @@ chapters follow which describe specific aspects of Bison in detail. Bison was written primarily by Robert Corbett; Richard Stallman made it Yacc-compatible. Wilfred Hansen of Carnegie Mellon University added -multicharacter string literals and other features. +multi-character string literals and other features. This edition corresponds to version @value{VERSION} of Bison. @@ -1859,17 +1859,20 @@ The symbol table itself consists of a linked list of records. Its definition, which is kept in the header @file{calc.h}, is as follows. It provides for either functions or variables to be placed in the table. -@c FIXME: ANSIfy the prototypes for FNCTPTR etc. @smallexample @group +/* Fonctions type. */ +typedef double (*func_t) (double); + /* Data type for links in the chain of symbols. */ struct symrec @{ char *name; /* name of symbol */ int type; /* type of symbol: either VAR or FNCT */ - union @{ - double var; /* value of a VAR */ - double (*fnctptr)(); /* value of a FNCT */ + union + @{ + double var; /* value of a VAR */ + func_t fnctptr; /* value of a FNCT */ @} value; struct symrec *next; /* link field */ @}; @@ -1881,8 +1884,8 @@ typedef struct symrec symrec; /* The symbol table: a chain of `struct symrec'. */ extern symrec *sym_table; -symrec *putsym (); -symrec *getsym (); +symrec *putsym (const char *, func_t); +symrec *getsym (const char *); @end group @end smallexample @@ -1912,24 +1915,24 @@ yyerror (const char *s) /* Called by yyparse on error */ struct init @{ char *fname; - double (*fnct)(); + double (*fnct)(double); @}; @end group @group struct init arith_fncts[] = @{ - "sin", sin, - "cos", cos, + "sin", sin, + "cos", cos, "atan", atan, - "ln", log, - "exp", exp, + "ln", log, + "exp", exp, "sqrt", sqrt, 0, 0 @}; /* The symbol table: a chain of `struct symrec'. */ -symrec *sym_table = (symrec *)0; +symrec *sym_table = (symrec *) 0; @end group @group @@ -1987,7 +1990,7 @@ getsym (const char *sym_name) The function @code{yylex} must now recognize variables, numeric values, and the single-character arithmetic operators. Strings of alphanumeric -characters with a leading nondigit are recognized as either variables or +characters with a leading non-digit are recognized as either variables or functions depending on what the symbol table says about them. The string is passed to @code{getsym} for look up in the symbol table. If @@ -2270,7 +2273,7 @@ for @code{yylex}}). A @dfn{literal string token} is written like a C string constant; for example, @code{"<="} is a literal string token. A literal string token doesn't need to be declared unless you need to specify its semantic -value data type (@pxref{Value Type}), associativity, precedence +value data type (@pxref{Value Type}), associativity, or precedence (@pxref{Precedence}). You can associate the literal string token with a symbolic name as an @@ -2544,10 +2547,11 @@ Specify the entire collection of possible data types, with the @code{%union} Bison declaration (@pxref{Union Decl, ,The Collection of Value Types}). @item -Choose one of those types for each symbol (terminal or nonterminal) -for which semantic values are used. This is done for tokens with the -@code{%token} Bison declaration (@pxref{Token Decl, ,Token Type Names}) and for groupings -with the @code{%type} Bison declaration (@pxref{Type Decl, ,Nonterminal Symbols}). +Choose one of those types for each symbol (terminal or nonterminal) for +which semantic values are used. This is done for tokens with the +@code{%token} Bison declaration (@pxref{Token Decl, ,Token Type Names}) +and for groupings with the @code{%type} Bison declaration (@pxref{Type +Decl, ,Nonterminal Symbols}). @end itemize @node Actions, Action Types, Multiple Types, Semantics @@ -2879,9 +2883,10 @@ Bison will convert this into a @code{#define} directive in the parser, so that the function @code{yylex} (if it is in this file) can use the name @var{name} to stand for this token type's code. -Alternatively, you can use @code{%left}, @code{%right}, or @code{%nonassoc} -instead of @code{%token}, if you wish to specify associativity and precedence. -@xref{Precedence Decl, ,Operator Precedence}. +Alternatively, you can use @code{%left}, @code{%right}, or +@code{%nonassoc} instead of @code{%token}, if you wish to specify +associativity and precedence. @xref{Precedence Decl, ,Operator +Precedence}. You can explicitly specify the numeric code for a token type by appending an integer value in the field immediately following the token name: @@ -3114,8 +3119,8 @@ may override this restriction with the @code{%start} declaration as follows: A @dfn{reentrant} program is one which does not alter in the course of execution; in other words, it consists entirely of @dfn{pure} (read-only) code. Reentrancy is important whenever asynchronous execution is possible; -for example, a nonreentrant program may not be safe to call from a signal -handler. In systems with multiple threads of control, a nonreentrant +for example, a non-reentrant program may not be safe to call from a signal +handler. In systems with multiple threads of control, a non-reentrant program must be called only within interlocks. Normally, Bison generates a parser which is not reentrant. This is @@ -3180,14 +3185,37 @@ Declare the type of semantic values for a nonterminal symbol (@pxref{Type Decl, ,Nonterminal Symbols}). @item %start -Specify the grammar's start symbol (@pxref{Start Decl, ,The Start-Symbol}). +Specify the grammar's start symbol (@pxref{Start Decl, ,The +Start-Symbol}). @item %expect Declare the expected number of shift-reduce conflicts (@pxref{Expect Decl, ,Suppressing Conflict Warnings}). +@item %yacc +@itemx %fixed_output_files +Pretend the option @option{--yacc} was given, i.e., imitate Yacc, +including its naming conventions. @xref{Bison Options}, for more. + +@item %locations +Generate the code processing the locations (@pxref{Action Features, +,Special Features for Use in Actions}). This mode is enabled as soon as +the grammar uses the special @samp{@@@var{n}} tokens, but if your +grammar does not use it, using @samp{%locations} allows for more +accurate parse error messages. + @item %pure_parser -Request a pure (reentrant) parser program (@pxref{Pure Decl, ,A Pure (Reentrant) Parser}). +Request a pure (reentrant) parser program (@pxref{Pure Decl, ,A Pure +(Reentrant) Parser}). + +@item %no_parser +Do not include any C code in the parser file; generate tables only. The +parser file contains just @code{#define} directives and static variable +declarations. + +This option also tells Bison to write the C code for the grammar actions +into a file named @file{@var{filename}.act}, in the form of a +brace-surrounded body fit for a @code{switch} statement. @item %no_lines Don't generate any @code{#line} preprocessor commands in the parser @@ -3197,12 +3225,38 @@ your source file (the grammar file). This directive causes them to associate errors with the parser file, treating it an independent source file in its own right. -@item %raw -The output file @file{@var{name}.h} normally defines the tokens with -Yacc-compatible token numbers. If this option is specified, the -internal Bison numbers are used instead. (Yacc-compatible numbers start -at 257 except for single-character tokens; Bison assigns token numbers -sequentially for all tokens starting at 3.) +@item %debug +Output a definition of the macro @code{YYDEBUG} into the parser file, so +that the debugging facilities are compiled. @xref{Debugging, ,Debugging +Your Parser}. + +@item %defines +Write an extra output file containing macro definitions for the token +type names defined in the grammar and the semantic value type +@code{YYSTYPE}, as well as a few @code{extern} variable declarations. + +If the parser output file is named @file{@var{name}.c} then this file +is named @file{@var{name}.h}.@refill + +This output file is essential if you wish to put the definition of +@code{yylex} in a separate source file, because @code{yylex} needs to +be able to refer to token type codes and the variable +@code{yylval}. @xref{Token Values, ,Semantic Values of Tokens}.@refill + +@item %verbose +Write an extra output file containing verbose descriptions of the +parser states and what is done for each type of look-ahead token in +that state. + +This file also describes all the conflicts, both those resolved by +operator precedence and the unresolved ones. + +The file's name is made by removing @samp{.tab.c} or @samp{.c} from +the parser output file name, and adding @samp{.output} instead.@refill + +Therefore, if the input file is @file{foo.y}, then the parser file is +called @file{foo.tab.c} by default. As a consequence, the verbose +output file is called @file{foo.output}.@refill @item %token_table Generate an array of token names in the parser file. The name of the @@ -3297,8 +3351,8 @@ C code in the grammar file, you are likely to run into trouble. You call the function @code{yyparse} to cause parsing to occur. This function reads tokens, executes actions, and ultimately returns when it encounters end-of-input or an unrecoverable syntax error. You can also -write an action which directs @code{yyparse} to return immediately without -reading further. +write an action which directs @code{yyparse} to return immediately +without reading further. The value returned by @code{yyparse} is 0 if parsing was successful (return is due to end-of-input). @@ -3428,7 +3482,7 @@ The @code{yytname} table is generated only if you use the @subsection Semantic Values of Tokens @vindex yylval -In an ordinary (nonreentrant) parser, the semantic value of the token must +In an ordinary (non-reentrant) parser, the semantic value of the token must be stored into the global variable @code{yylval}. When you are using just one data type for semantic values, @code{yylval} has that type. Thus, if the type is @code{int} (the default), you might write this in @@ -3474,16 +3528,17 @@ then the code in @code{yylex} might look like this: @subsection Textual Positions of Tokens @vindex yylloc -If you are using the @samp{@@@var{n}}-feature (@pxref{Action Features, ,Special Features for Use in Actions}) in -actions to keep track of the textual locations of tokens and groupings, -then you must provide this information in @code{yylex}. The function -@code{yyparse} expects to find the textual location of a token just parsed -in the global variable @code{yylloc}. So @code{yylex} must store the -proper data in that variable. The value of @code{yylloc} is a structure -and you need only initialize the members that are going to be used by the -actions. The four members are called @code{first_line}, -@code{first_column}, @code{last_line} and @code{last_column}. Note that -the use of this feature makes the parser noticeably slower. +If you are using the @samp{@@@var{n}}-feature (@pxref{Action Features, +,Special Features for Use in Actions}) in actions to keep track of the +textual locations of tokens and groupings, then you must provide this +information in @code{yylex}. The function @code{yyparse} expects to +find the textual location of a token just parsed in the global variable +@code{yylloc}. So @code{yylex} must store the proper data in that +variable. The value of @code{yylloc} is a structure and you need only +initialize the members that are going to be used by the actions. The +four members are called @code{first_line}, @code{first_column}, +@code{last_line} and @code{last_column}. Note that the use of this +feature makes the parser noticeably slower. @tindex YYLTYPE The data type of @code{yylloc} has the name @code{YYLTYPE}. @@ -4014,33 +4069,33 @@ expr: expr '-' expr @noindent Suppose the parser has seen the tokens @samp{1}, @samp{-} and @samp{2}; -should it reduce them via the rule for the subtraction operator? It depends -on the next token. Of course, if the next token is @samp{)}, we must -reduce; shifting is invalid because no single rule can reduce the token -sequence @w{@samp{- 2 )}} or anything starting with that. But if the next -token is @samp{*} or @samp{<}, we have a choice: either shifting or -reduction would allow the parse to complete, but with different -results. - -To decide which one Bison should do, we must consider the -results. If the next operator token @var{op} is shifted, then it -must be reduced first in order to permit another opportunity to -reduce the difference. The result is (in effect) @w{@samp{1 - (2 -@var{op} 3)}}. On the other hand, if the subtraction is reduced -before shifting @var{op}, the result is @w{@samp{(1 - 2) @var{op} -3}}. Clearly, then, the choice of shift or reduce should depend -on the relative precedence of the operators @samp{-} and -@var{op}: @samp{*} should be shifted first, but not @samp{<}. +should it reduce them via the rule for the subtraction operator? It +depends on the next token. Of course, if the next token is @samp{)}, we +must reduce; shifting is invalid because no single rule can reduce the +token sequence @w{@samp{- 2 )}} or anything starting with that. But if +the next token is @samp{*} or @samp{<}, we have a choice: either +shifting or reduction would allow the parse to complete, but with +different results. + +To decide which one Bison should do, we must consider the results. If +the next operator token @var{op} is shifted, then it must be reduced +first in order to permit another opportunity to reduce the difference. +The result is (in effect) @w{@samp{1 - (2 @var{op} 3)}}. On the other +hand, if the subtraction is reduced before shifting @var{op}, the result +is @w{@samp{(1 - 2) @var{op} 3}}. Clearly, then, the choice of shift or +reduce should depend on the relative precedence of the operators +@samp{-} and @var{op}: @samp{*} should be shifted first, but not +@samp{<}. @cindex associativity What about input such as @w{@samp{1 - 2 - 5}}; should this be -@w{@samp{(1 - 2) - 5}} or should it be @w{@samp{1 - (2 - 5)}}? For -most operators we prefer the former, which is called @dfn{left -association}. The latter alternative, @dfn{right association}, is -desirable for assignment operators. The choice of left or right -association is a matter of whether the parser chooses to shift or -reduce when the stack contains @w{@samp{1 - 2}} and the look-ahead -token is @samp{-}: shifting makes right-associativity. +@w{@samp{(1 - 2) - 5}} or should it be @w{@samp{1 - (2 - 5)}}? For most +operators we prefer the former, which is called @dfn{left association}. +The latter alternative, @dfn{right association}, is desirable for +assignment operators. The choice of left or right association is a +matter of whether the parser chooses to shift or reduce when the stack +contains @w{@samp{1 - 2}} and the look-ahead token is @samp{-}: shifting +makes right-associativity. @node Using Precedence, Precedence Examples, Why Precedence, Precedence @subsection Specifying Operator Precedence @@ -4632,10 +4687,10 @@ 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: +all the nonterminal names changed: once for parsing a declaration in +which a typedef name can be redefined, and once for parsing a +declaration in which that can't be done. Here is a part of the +duplication, with actions omitted for brevity: @example initdcl: @@ -4894,50 +4949,50 @@ 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. -@table @samp -@item -b @var{file-prefix} -@itemx --file-prefix=@var{prefix} -Specify a prefix to use for all Bison output file names. The names are -chosen as if the input file were named @file{@var{prefix}.c}. - -@item -d -@itemx --defines -Write an extra output file containing macro definitions for the token -type names defined in the grammar and the semantic value type -@code{YYSTYPE}, as well as a few @code{extern} variable declarations. +@c Please, keep this ordered as in `bison --help'. +@noindent +Operations modes: +@table @option +@item -h +@itemx --help +Print a summary of the command-line options to Bison and exit. -If the parser output file is named @file{@var{name}.c} then this file -is named @file{@var{name}.h}.@refill +@item -V +@itemx --version +Print the version number of Bison and exit. -This output file is essential if you wish to put the definition of -@code{yylex} in a separate source file, because @code{yylex} needs to -be able to refer to token type codes and the variable -@code{yylval}. @xref{Token Values, ,Semantic Values of Tokens}.@refill +@need 1750 +@item -y +@itemx --yacc +@itemx --fixed-output-files +Equivalent to @samp{-o y.tab.c}; the parser output file is called +@file{y.tab.c}, and the other outputs are called @file{y.output} and +@file{y.tab.h}. The purpose of this option is to imitate Yacc's output +file name conventions. Thus, the following shell script can substitute +for Yacc:@refill -@item -l -@itemx --no-lines -Don't put any @code{#line} preprocessor commands in the parser file. -Ordinarily Bison puts them in the parser file so that the C compiler -and debuggers will associate errors with your source file, the -grammar file. This option causes them to associate errors with the -parser file, treating it as an independent source file in its own right. +@example +bison -y $* +@end example +@end table -@item -n -@itemx --no-parser -Do not include any C code in the parser file; generate tables only. The -parser file contains just @code{#define} directives and static variable -declarations. +@noindent +Tuning the parser: -This option also tells Bison to write the C code for the grammar actions -into a file named @file{@var{filename}.act}, in the form of a -brace-surrounded body fit for a @code{switch} statement. +@table @option +@item -S @var{file} +@itemx --skeleton=@var{file} +Specify the skeleton to use. You probably don't need this option unless +you are developing Bison. -@item -o @var{outfile} -@itemx --output-file=@var{outfile} -Specify the name @var{outfile} for the parser file. +@item -t +@itemx --debug +Output a definition of the macro @code{YYDEBUG} into the parser file, so +that the debugging facilities are compiled. @xref{Debugging, ,Debugging +Your Parser}. -The other output files' names are constructed from @var{outfile} -as described under the @samp{-v} and @samp{-d} options. +@item --locations +Pretend that @code{%locactions} was specified. @xref{Decl Summary}. @item -p @var{prefix} @itemx --name-prefix=@var{prefix} @@ -4951,52 +5006,51 @@ For example, if you use @samp{-p c}, the names become @code{cparse}, @xref{Multiple Parsers, ,Multiple Parsers in the Same Program}. -@item -r -@itemx --raw -Pretend that @code{%raw} was specified. @xref{Decl Summary}. - -@item -t -@itemx --debug -Output a definition of the macro @code{YYDEBUG} into the parser file, -so that the debugging facilities are compiled. @xref{Debugging, ,Debugging Your Parser}. +@item -l +@itemx --no-lines +Don't put any @code{#line} preprocessor commands in the parser file. +Ordinarily Bison puts them in the parser file so that the C compiler +and debuggers will associate errors with your source file, the +grammar file. This option causes them to associate errors with the +parser file, treating it as an independent source file in its own right. -@item -v -@itemx --verbose -Write an extra output file containing verbose descriptions of the -parser states and what is done for each type of look-ahead token in -that state. +@item -n +@itemx --no-parser +Pretend that @code{%no_parser} was specified. @xref{Decl Summary}. -This file also describes all the conflicts, both those resolved by -operator precedence and the unresolved ones. +@item -k +@itemx --token-table +Pretend that @code{%token_table} was specified. @xref{Decl Summary}. +@end table -The file's name is made by removing @samp{.tab.c} or @samp{.c} from -the parser output file name, and adding @samp{.output} instead.@refill +@noindent +Adjust the output: -Therefore, if the input file is @file{foo.y}, then the parser file is -called @file{foo.tab.c} by default. As a consequence, the verbose -output file is called @file{foo.output}.@refill +@table @option +@item -d +@itemx --defines +Pretend that @code{%verbose} was specified, i.e., write an extra output +file containing macro definitions for the token type names defined in +the grammar and the semantic value type @code{YYSTYPE}, as well as a few +@code{extern} variable declarations. @xref{Decl Summary}. -@item -V -@itemx --version -Print the version number of Bison and exit. +@item -b @var{file-prefix} +@itemx --file-prefix=@var{prefix} +Specify a prefix to use for all Bison output file names. The names are +chosen as if the input file were named @file{@var{prefix}.c}. -@item -h -@itemx --help -Print a summary of the command-line options to Bison and exit. +@item -v +@itemx --verbose +Pretend that @code{%verbose} was specified, i.e, write an extra output +file containing verbose descriptions of the grammar and +parser. @xref{Decl Summary}, for more. -@need 1750 -@item -y -@itemx --yacc -@itemx --fixed-output-files -Equivalent to @samp{-o y.tab.c}; the parser output file is called -@file{y.tab.c}, and the other outputs are called @file{y.output} and -@file{y.tab.h}. The purpose of this option is to imitate Yacc's output -file name conventions. Thus, the following shell script can substitute -for Yacc:@refill +@item -o @var{outfile} +@itemx --output-file=@var{outfile} +Specify the name @var{outfile} for the parser file. -@example -bison -y $* -@end example +The other output files' names are constructed from @var{outfile} +as described under the @samp{-v} and @samp{-d} options. @end table @node Environment Variables, Option Cross Key, Bison Options, Invocation @@ -5043,7 +5097,6 @@ the corresponding short option. \line{ --no-lines \leaderfill -l} \line{ --no-parser \leaderfill -n} \line{ --output-file \leaderfill -o} -\line{ --raw \leaderfill -r} \line{ --token-table \leaderfill -k} \line{ --verbose \leaderfill -v} \line{ --version \leaderfill -V} @@ -5062,7 +5115,6 @@ the corresponding short option. --no-lines -l --no-parser -n --output-file=@var{outfile} -o @var{outfile} ---raw -r --token-table -k --verbose -v --version -V @@ -5223,6 +5275,13 @@ Global variable which Bison increments each time there is a parse error. The parser function produced by Bison; call this function to start parsing. @xref{Parser Function, ,The Parser Function @code{yyparse}}. +@item %debug +Equip the parser for debugging. @xref{Decl Summary}. + +@item %defines +Bison declaration to create a header file meant for the scanner. +@xref{Decl Summary}. + @item %left Bison declaration to assign left associativity to token(s). @xref{Precedence Decl, ,Operator Precedence}. @@ -5232,7 +5291,7 @@ Bison declaration to avoid generating @code{#line} directives in the parser file. @xref{Decl Summary}. @item %nonassoc -Bison declaration to assign nonassociativity to token(s). +Bison declaration to assign non-associativity to token(s). @xref{Precedence Decl, ,Operator Precedence}. @item %prec @@ -5243,11 +5302,6 @@ Bison declaration to assign a precedence to a specific rule. Bison declaration to request a pure (reentrant) parser. @xref{Pure Decl, ,A Pure (Reentrant) Parser}. -@item %raw -Bison declaration to use Bison internal token code numbers in token -tables instead of the usual Yacc-compatible token code numbers. -@xref{Decl Summary}. - @item %right Bison declaration to assign right associativity to token(s). @xref{Precedence Decl, ,Operator Precedence}. @@ -5280,15 +5334,17 @@ Bison declarations section or the additional C code section. @xref{Grammar Layout, ,The Overall Layout of a Bison Grammar}. @item %@{ %@} -All code listed between @samp{%@{} and @samp{%@}} is copied directly -to the output file uninterpreted. Such code forms the ``C -declarations'' section of the input file. @xref{Grammar Outline, ,Outline of a Bison Grammar}. +All code listed between @samp{%@{} and @samp{%@}} is copied directly to +the output file uninterpreted. Such code forms the ``C declarations'' +section of the input file. @xref{Grammar Outline, ,Outline of a Bison +Grammar}. @item /*@dots{}*/ Comment delimiters, as in C. @item : -Separates a rule's result from its components. @xref{Rules, ,Syntax of Grammar Rules}. +Separates a rule's result from its components. @xref{Rules, ,Syntax of +Grammar Rules}. @item ; Terminates a rule. @xref{Rules, ,Syntax of Grammar Rules}. @@ -5305,13 +5361,15 @@ Separates alternate rules for the same result nonterminal. @table @asis @item Backus-Naur Form (BNF) Formal method of specifying context-free grammars. BNF was first used -in the @cite{ALGOL-60} report, 1963. @xref{Language and Grammar, ,Languages and Context-Free Grammars}. +in the @cite{ALGOL-60} report, 1963. @xref{Language and Grammar, +,Languages and Context-Free Grammars}. @item Context-free grammars Grammars specified as rules that can be applied regardless of context. Thus, if there is a rule which says that an integer can be used as an expression, integers are allowed @emph{anywhere} an expression is -permitted. @xref{Language and Grammar, ,Languages and Context-Free Grammars}. +permitted. @xref{Language and Grammar, ,Languages and Context-Free +Grammars}. @item Dynamic allocation Allocation of memory that occurs during execution, rather than at @@ -5352,8 +5410,9 @@ Operators having left associativity are analyzed from left to right: @samp{c}. @xref{Precedence, ,Operator Precedence}. @item Left recursion -A rule whose result symbol is also its first component symbol; -for example, @samp{expseq1 : expseq1 ',' exp;}. @xref{Recursion, ,Recursive Rules}. +A rule whose result symbol is also its first component symbol; for +example, @samp{expseq1 : expseq1 ',' exp;}. @xref{Recursion, ,Recursive +Rules}. @item Left-to-right parsing Parsing a sentence of a language by analyzing it token by token from @@ -5368,11 +5427,11 @@ A flag, set by actions in the grammar rules, which alters the way tokens are parsed. @xref{Lexical Tie-ins}. @item Literal string token -A token which consists of two or more fixed characters. -@xref{Symbols}. +A token which consists of two or more fixed characters. @xref{Symbols}. @item Look-ahead token -A token already read but not yet shifted. @xref{Look-Ahead, ,Look-Ahead Tokens}. +A token already read but not yet shifted. @xref{Look-Ahead, ,Look-Ahead +Tokens}. @item LALR(1) The class of context-free grammars that Bison (like most other parser @@ -5403,7 +5462,8 @@ performs some operation. @item Reduction Replacing a string of nonterminals and/or terminals with a single -nonterminal, according to a grammar rule. @xref{Algorithm, ,The Bison Parser Algorithm }. +nonterminal, according to a grammar rule. @xref{Algorithm, ,The Bison +Parser Algorithm }. @item Reentrant A reentrant subprogram is a subprogram which can be in invoked any @@ -5414,8 +5474,9 @@ invocations. @xref{Pure Decl, ,A Pure (Reentrant) Parser}. A language in which all operators are postfix operators. @item Right recursion -A rule whose result symbol is also its last component symbol; -for example, @samp{expseq1: exp ',' expseq1;}. @xref{Recursion, ,Recursive Rules}. +A rule whose result symbol is also its last component symbol; for +example, @samp{expseq1: exp ',' expseq1;}. @xref{Recursion, ,Recursive +Rules}. @item Semantics In computer languages, the semantics are specified by the actions @@ -5449,9 +5510,9 @@ The input of the Bison parser is a stream of tokens which comes from the lexical analyzer. @xref{Symbols}. @item 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. @xref{Language and Grammar, ,Languages and Context-Free Grammars}. +A grammar symbol that has no rules in the grammar and therefore is +grammatically indivisible. The piece of text it represents is a token. +@xref{Language and Grammar, ,Languages and Context-Free Grammars}. @end table @node Index, , Glossary, Top