bison.info-1: 1307
bison.info-2: 50189
bison.info-3: 99814
-bison.info-4: 149693
-bison.info-5: 196958
+bison.info-4: 148012
+bison.info-5: 190796
\1f
Tag Table:
(Indirect)
Node: Action Types\7f98511
Node: Mid-Rule Actions\7f99814
Node: Locations\7f105384
-Node: Location Type\7f106049
-Node: Actions and Locations\7f106607
-Node: Location Default Action\7f107771
-Node: Declarations\7f108978
-Node: Token Decl\7f110297
-Node: Precedence Decl\7f112310
-Node: Union Decl\7f113861
-Node: Type Decl\7f114705
-Node: Expect Decl\7f115611
-Node: Start Decl\7f117157
-Node: Pure Decl\7f117535
-Node: Decl Summary\7f119212
-Node: Multiple Parsers\7f124595
-Node: Interface\7f126089
-Node: Parser Function\7f126961
-Node: Lexical\7f127796
-Node: Calling Convention\7f129202
-Node: Token Values\7f131973
-Node: Token Positions\7f133122
-Node: Pure Calling\7f134007
-Node: Error Reporting\7f136939
-Node: Action Features\7f139061
-Node: Algorithm\7f142356
-Node: Look-Ahead\7f144649
-Node: Shift/Reduce\7f146781
-Node: Precedence\7f149693
-Node: Why Precedence\7f150344
-Node: Using Precedence\7f152209
-Node: Precedence Examples\7f153177
-Node: How Precedence\7f153878
-Node: Contextual Precedence\7f155027
-Node: Parser States\7f156818
-Node: Reduce/Reduce\7f158061
-Node: Mystery Conflicts\7f161622
-Node: Stack Overflow\7f165008
-Node: Error Recovery\7f166381
-Node: Context Dependency\7f171517
-Node: Semantic Tokens\7f172365
-Node: Lexical Tie-ins\7f175382
-Node: Tie-in Recovery\7f176930
-Node: Debugging\7f179102
-Node: Invocation\7f182403
-Node: Bison Options\7f183655
-Node: Environment Variables\7f187089
-Node: Option Cross Key\7f187937
-Node: VMS Invocation\7f188781
-Node: Table of Symbols\7f189565
-Node: Glossary\7f196958
-Node: Index\7f203248
+Node: Location Type\7f106032
+Node: Actions and Locations\7f106590
+Node: Location Default Action\7f108746
+Node: Declarations\7f110209
+Node: Token Decl\7f111528
+Node: Precedence Decl\7f113541
+Node: Union Decl\7f115092
+Node: Type Decl\7f115936
+Node: Expect Decl\7f116842
+Node: Start Decl\7f118388
+Node: Pure Decl\7f118766
+Node: Decl Summary\7f120443
+Node: Multiple Parsers\7f125826
+Node: Interface\7f127320
+Node: Parser Function\7f128192
+Node: Lexical\7f129027
+Node: Calling Convention\7f130433
+Node: Token Values\7f133204
+Node: Token Positions\7f134353
+Node: Pure Calling\7f135238
+Node: Error Reporting\7f138170
+Node: Action Features\7f140292
+Node: Algorithm\7f143587
+Node: Look-Ahead\7f145880
+Node: Shift/Reduce\7f148012
+Node: Precedence\7f150924
+Node: Why Precedence\7f151575
+Node: Using Precedence\7f153440
+Node: Precedence Examples\7f154408
+Node: How Precedence\7f155109
+Node: Contextual Precedence\7f156258
+Node: Parser States\7f158049
+Node: Reduce/Reduce\7f159292
+Node: Mystery Conflicts\7f162853
+Node: Stack Overflow\7f166239
+Node: Error Recovery\7f167612
+Node: Context Dependency\7f172748
+Node: Semantic Tokens\7f173596
+Node: Lexical Tie-ins\7f176613
+Node: Tie-in Recovery\7f178161
+Node: Debugging\7f180333
+Node: Invocation\7f183634
+Node: Bison Options\7f184886
+Node: Environment Variables\7f188320
+Node: Option Cross Key\7f189168
+Node: VMS Invocation\7f190012
+Node: Table of Symbols\7f190796
+Node: Glossary\7f198189
+Node: Index\7f204479
\1f
End Tag Table
Though grammar rules and semantic actions are enough to write a fully
functional parser, it can be useful to process some additionnal
-informations, especially locations of tokens and groupings.
+informations, especially symbol locations.
The way locations are handled is defined by providing a data type,
and actions to take when rules are matched.
hand side is `@N', while the location of the left hand side grouping is
`@$'.
- Here is a simple example using the default data type for locations:
+ Here is a basic example using the default data type for locations:
exp: ...
- | exp '+' exp
+ | exp '/' exp
{
+ @$.first_column = @1.first_column;
+ @$.first_line = @1.first_line;
@$.last_column = @3.last_column;
@$.last_line = @3.last_line;
- $$ = $1 + $3;
+ if ($3)
+ $$ = $1 / $3;
+ else
+ {
+ $$ = 1;
+ printf("Division by zero, l%d,c%d-l%d,c%d",
+ @3.first_line, @3.first_column,
+ @3.last_line, @3.last_column);
+ }
}
-In the example above, there is no need to set the beginning of `@$'. The
-output parser always sets `@$' to `@1' before executing the C code of a
-given action, whether you provide a processing for locations or not.
+ As for semantic values, there is a default action for locations that
+is run each time a rule is matched. It sets the beginning of `@$' to the
+beginning of the first symbol, and the end of `@$' to the end of the
+last symbol.
+
+ With this default action, the location tracking can be fully
+automatic. The example above simply rewrites this way:
+
+ exp: ...
+ | exp '/' exp
+ {
+ if ($3)
+ $$ = $1 / $3;
+ else
+ {
+ $$ = 1;
+ printf("Division by zero, l%d,c%d-l%d,c%d",
+ @3.first_line, @3.first_column,
+ @3.last_line, @3.last_column);
+ }
+ }
\1f
File: bison.info, Node: Location Default Action, Prev: Actions and Locations, Up: Locations
Actually, actions are not the best place to compute locations. Since
locations are much more general than semantic values, there is room in
-the output parser to define a default action to take for each rule. The
-`YYLLOC_DEFAULT' macro is called each time a rule is matched, before
-the associated action is run.
+the output parser to redefine the default action to take for each rule.
+The `YYLLOC_DEFAULT' macro is called each time a rule is matched,
+before the associated action is run.
+
+ Most of the time, this macro is general enough to suppress location
+dedicated code from semantic actions.
+
+ The `YYLLOC_DEFAULT' macro takes three parameters. The first one is
+the location of the grouping (the result of the computation). The
+second one is an array holding locations of all right hand side
+elements of the rule being matched. The last one is the size of the
+right hand side rule.
+
+ By default, it is defined this way:
- This macro takes two parameters, the first one being the location of
-the grouping (the result of the computation), and the second one being
-the location of the last element matched. Of course, before
-`YYLLOC_DEFAULT' is run, the result is set to the location of the first
-component matched.
+ #define YYLLOC_DEFAULT(Current, Rhs, N) \
+ Current.last_line = Rhs[N].last_line; \
+ Current.last_column = Rhs[N].last_column;
- By default, this macro computes a location that ranges from the
-beginning of the first element to the end of the last element. It is
-defined this way:
+ When defining `YYLLOC_DEFAULT', you should consider that:
- #define YYLLOC_DEFAULT(Current, Last) \
- Current.last_line = Last.last_line; \
- Current.last_column = Last.last_column;
+ * All arguments are free of side-effects. However, only the first
+ one (the result) should be modified by `YYLLOC_DEFAULT'.
-Most of the time, the default action for locations is general enough to
-suppress location dedicated code from most actions.
+ * Before `YYLLOC_DEFAULT' is executed, the output parser sets `@$'
+ to `@1'.
+
+ * For consistency with semantic actions, valid indexes for the
+ location array range from 1 to N.
\1f
File: bison.info, Node: Declarations, Next: Multiple Parsers, Prev: Locations, Up: Grammar File
The current look-ahead token is stored in the variable `yychar'.
*Note Special Features for Use in Actions: Action Features.
-\1f
-File: bison.info, Node: Shift/Reduce, Next: Precedence, Prev: Look-Ahead, Up: Algorithm
-
-Shift/Reduce Conflicts
-======================
-
- Suppose we are parsing a language which has if-then and if-then-else
-statements, with a pair of rules like this:
-
- if_stmt:
- IF expr THEN stmt
- | IF expr THEN stmt ELSE stmt
- ;
-
-Here we assume that `IF', `THEN' and `ELSE' are terminal symbols for
-specific keyword tokens.
-
- When the `ELSE' token is read and becomes the look-ahead token, the
-contents of the stack (assuming the input is valid) are just right for
-reduction by the first rule. But it is also legitimate to shift the
-`ELSE', because that would lead to eventual reduction by the second
-rule.
-
- This situation, where either a shift or a reduction would be valid,
-is called a "shift/reduce conflict". Bison is designed to resolve
-these conflicts by choosing to shift, unless otherwise directed by
-operator precedence declarations. To see the reason for this, let's
-contrast it with the other alternative.
-
- Since the parser prefers to shift the `ELSE', the result is to attach
-the else-clause to the innermost if-statement, making these two inputs
-equivalent:
-
- if x then if y then win (); else lose;
-
- if x then do; if y then win (); else lose; end;
-
- But if the parser chose to reduce when possible rather than shift,
-the result would be to attach the else-clause to the outermost
-if-statement, making these two inputs equivalent:
-
- if x then if y then win (); else lose;
-
- if x then do; if y then win (); end; else lose;
-
- The conflict exists because the grammar as written is ambiguous:
-either parsing of the simple nested if-statement is legitimate. The
-established convention is that these ambiguities are resolved by
-attaching the else-clause to the innermost if-statement; this is what
-Bison accomplishes by choosing to shift rather than reduce. (It would
-ideally be cleaner to write an unambiguous grammar, but that is very
-hard to do in this case.) This particular ambiguity was first
-encountered in the specifications of Algol 60 and is called the
-"dangling `else'" ambiguity.
-
- To avoid warnings from Bison about predictable, legitimate
-shift/reduce conflicts, use the `%expect N' declaration. There will be
-no warning as long as the number of shift/reduce conflicts is exactly N.
-*Note Suppressing Conflict Warnings: Expect Decl.
-
- The definition of `if_stmt' above is solely to blame for the
-conflict, but the conflict does not actually appear without additional
-rules. Here is a complete Bison input file that actually manifests the
-conflict:
-
- %token IF THEN ELSE variable
- %%
- stmt: expr
- | if_stmt
- ;
-
- if_stmt:
- IF expr THEN stmt
- | IF expr THEN stmt ELSE stmt
- ;
-
- expr: variable
- ;
-
included in translations approved by the Free Software Foundation
instead of in the original English.
+\1f
+File: bison.info, Node: Shift/Reduce, Next: Precedence, Prev: Look-Ahead, Up: Algorithm
+
+Shift/Reduce Conflicts
+======================
+
+ Suppose we are parsing a language which has if-then and if-then-else
+statements, with a pair of rules like this:
+
+ if_stmt:
+ IF expr THEN stmt
+ | IF expr THEN stmt ELSE stmt
+ ;
+
+Here we assume that `IF', `THEN' and `ELSE' are terminal symbols for
+specific keyword tokens.
+
+ When the `ELSE' token is read and becomes the look-ahead token, the
+contents of the stack (assuming the input is valid) are just right for
+reduction by the first rule. But it is also legitimate to shift the
+`ELSE', because that would lead to eventual reduction by the second
+rule.
+
+ This situation, where either a shift or a reduction would be valid,
+is called a "shift/reduce conflict". Bison is designed to resolve
+these conflicts by choosing to shift, unless otherwise directed by
+operator precedence declarations. To see the reason for this, let's
+contrast it with the other alternative.
+
+ Since the parser prefers to shift the `ELSE', the result is to attach
+the else-clause to the innermost if-statement, making these two inputs
+equivalent:
+
+ if x then if y then win (); else lose;
+
+ if x then do; if y then win (); else lose; end;
+
+ But if the parser chose to reduce when possible rather than shift,
+the result would be to attach the else-clause to the outermost
+if-statement, making these two inputs equivalent:
+
+ if x then if y then win (); else lose;
+
+ if x then do; if y then win (); end; else lose;
+
+ The conflict exists because the grammar as written is ambiguous:
+either parsing of the simple nested if-statement is legitimate. The
+established convention is that these ambiguities are resolved by
+attaching the else-clause to the innermost if-statement; this is what
+Bison accomplishes by choosing to shift rather than reduce. (It would
+ideally be cleaner to write an unambiguous grammar, but that is very
+hard to do in this case.) This particular ambiguity was first
+encountered in the specifications of Algol 60 and is called the
+"dangling `else'" ambiguity.
+
+ To avoid warnings from Bison about predictable, legitimate
+shift/reduce conflicts, use the `%expect N' declaration. There will be
+no warning as long as the number of shift/reduce conflicts is exactly N.
+*Note Suppressing Conflict Warnings: Expect Decl.
+
+ The definition of `if_stmt' above is solely to blame for the
+conflict, but the conflict does not actually appear without additional
+rules. Here is a complete Bison input file that actually manifests the
+conflict:
+
+ %token IF THEN ELSE variable
+ %%
+ stmt: expr
+ | if_stmt
+ ;
+
+ if_stmt:
+ IF expr THEN stmt
+ | IF expr THEN stmt ELSE stmt
+ ;
+
+ expr: variable
+ ;
+
\1f
File: bison.info, Node: Precedence, Next: Contextual Precedence, Prev: Shift/Reduce, Up: Algorithm
In the above example, the output file would instead be named
`foo_tab.c'.
-\1f
-File: bison.info, Node: Table of Symbols, Next: Glossary, Prev: Invocation, Up: Top
-
-Bison Symbols
-*************
-
-`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
- parse error, the token `error' becomes the current look-ahead
- token. Actions corresponding to `error' are then executed, and
- the look-ahead token is reset to the token that originally caused
- the violation. *Note Error Recovery::.
-
-`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.
-
-`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.
-
-`YYBACKUP'
- Macro to discard a value from the parser stack and fake a
- look-ahead token. *Note Special Features for Use in Actions:
- Action Features.
-
-`YYERROR'
- Macro to pretend that a syntax error has just been detected: call
- `yyerror' and then perform normal error recovery if possible
- (*note Error Recovery::), or (if recovery is impossible) make
- `yyparse' return 1. *Note Error Recovery::.
-
-`YYERROR_VERBOSE'
- Macro that you define with `#define' in the Bison declarations
- section to request verbose, specific error message strings when
- `yyerror' is called.
-
-`YYINITDEPTH'
- Macro for specifying the initial size of the parser stack. *Note
- Stack Overflow::.
-
-`YYLEX_PARAM'
- Macro for specifying an extra argument (or list of extra
- arguments) for `yyparse' to pass to `yylex'. *Note Calling
- Conventions for Pure Parsers: Pure Calling.
-
-`YYLTYPE'
- Macro for the data type of `yylloc'; a structure with four
- members. *Note Data Types of Locations: Location Type.
-
-`yyltype'
- Default value for YYLTYPE.
-
-`YYMAXDEPTH'
- Macro for specifying the maximum size of the parser stack. *Note
- Stack Overflow::.
-
-`YYPARSE_PARAM'
- Macro for specifying the name of a parameter that `yyparse' should
- accept. *Note Calling Conventions for Pure Parsers: Pure Calling.
-
-`YYRECOVERING'
- Macro whose value indicates whether the parser is recovering from a
- syntax error. *Note Special Features for Use in Actions: Action
- Features.
-
-`YYSTYPE'
- Macro for the data type of semantic values; `int' by default.
- *Note Data Types of Semantic Values: Value Type.
-
-`yychar'
- External integer variable that contains the integer value of the
- current look-ahead 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.
-
-`yyclearin'
- Macro used in error-recovery rule actions. It clears the previous
- look-ahead token. *Note Error Recovery::.
-
-`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 Debugging Your Parser: Debugging.
-
-`yyerrok'
- Macro to cause parser to recover immediately to its normal mode
- after a parse error. *Note Error Recovery::.
-
-`yyerror'
- User-supplied function to be called by `yyparse' on error. The
- function receives one argument, a pointer to a character string
- containing an error message. *Note The Error Reporting Function
- `yyerror': Error Reporting.
-
-`yylex'
- User-supplied lexical analyzer function, called with no arguments
- to get the next token. *Note The Lexical Analyzer Function
- `yylex': Lexical.
-
-`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.
-
-`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 Positions of Tokens: Token
- Positions.
-
-`yynerrs'
- Global variable which Bison increments each time there is a parse
- error. (In a pure parser, it is a local variable within
- `yyparse'.) *Note The Error Reporting Function `yyerror': Error
- Reporting.
-
-`yyparse'
- The parser function produced by Bison; call this function to start
- parsing. *Note The Parser Function `yyparse': Parser Function.
-
-`%debug'
- Equip the parser for debugging. *Note Decl Summary::.
-
-`%defines'
- Bison declaration to create a header file meant for the scanner.
- *Note Decl Summary::.
-
-`%left'
- Bison declaration to assign left associativity to token(s). *Note
- Operator Precedence: Precedence Decl.
-
-`%no_lines'
- Bison declaration to avoid generating `#line' directives in the
- parser file. *Note Decl Summary::.
-
-`%nonassoc'
- Bison declaration to assign non-associativity to token(s). *Note
- Operator Precedence: Precedence Decl.
-
-`%prec'
- Bison declaration to assign a precedence to a specific rule.
- *Note Context-Dependent Precedence: Contextual Precedence.
-
-`%pure_parser'
- Bison declaration to request a pure (reentrant) parser. *Note A
- Pure (Reentrant) Parser: Pure Decl.
-
-`%right'
- Bison declaration to assign right associativity to token(s).
- *Note Operator Precedence: Precedence Decl.
-
-`%start'
- Bison declaration to specify the start symbol. *Note The
- Start-Symbol: Start Decl.
-
-`%token'
- Bison declaration to declare token(s) without specifying
- precedence. *Note Token Type Names: Token Decl.
-
-`%token_table'
- Bison declaration to include a token name table in the parser file.
- *Note Decl Summary::.
-
-`%type'
- Bison declaration to declare nonterminals. *Note Nonterminal
- Symbols: Type Decl.
-
-`%union'
- Bison declaration to specify several possible data types for
- semantic values. *Note The Collection of Value Types: Union Decl.
-
- These are the punctuation and delimiters used in Bison input:
-
-`%%'
- Delimiter used to separate the grammar rule section from the Bison
- declarations section or the additional C code section. *Note The
- Overall Layout of a Bison Grammar: Grammar Layout.
-
-`%{ %}'
- All code listed between `%{' and `%}' is copied directly to the
- output file uninterpreted. Such code forms the "C declarations"
- section of the input file. *Note Outline of a Bison Grammar:
- Grammar Outline.
-
-`/*...*/'
- Comment delimiters, as in C.
-
-`:'
- Separates a rule's result from its components. *Note Syntax of
- Grammar Rules: Rules.
-
-`;'
- Terminates a rule. *Note Syntax of Grammar Rules: Rules.
-
-`|'
- Separates alternate rules for the same result nonterminal. *Note
- Syntax of Grammar Rules: Rules.
-
included in translations approved by the Free Software Foundation
instead of in the original English.
+\1f
+File: bison.info, Node: Table of Symbols, Next: Glossary, Prev: Invocation, Up: Top
+
+Bison Symbols
+*************
+
+`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
+ parse error, the token `error' becomes the current look-ahead
+ token. Actions corresponding to `error' are then executed, and
+ the look-ahead token is reset to the token that originally caused
+ the violation. *Note Error Recovery::.
+
+`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.
+
+`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.
+
+`YYBACKUP'
+ Macro to discard a value from the parser stack and fake a
+ look-ahead token. *Note Special Features for Use in Actions:
+ Action Features.
+
+`YYERROR'
+ Macro to pretend that a syntax error has just been detected: call
+ `yyerror' and then perform normal error recovery if possible
+ (*note Error Recovery::), or (if recovery is impossible) make
+ `yyparse' return 1. *Note Error Recovery::.
+
+`YYERROR_VERBOSE'
+ Macro that you define with `#define' in the Bison declarations
+ section to request verbose, specific error message strings when
+ `yyerror' is called.
+
+`YYINITDEPTH'
+ Macro for specifying the initial size of the parser stack. *Note
+ Stack Overflow::.
+
+`YYLEX_PARAM'
+ Macro for specifying an extra argument (or list of extra
+ arguments) for `yyparse' to pass to `yylex'. *Note Calling
+ Conventions for Pure Parsers: Pure Calling.
+
+`YYLTYPE'
+ Macro for the data type of `yylloc'; a structure with four
+ members. *Note Data Types of Locations: Location Type.
+
+`yyltype'
+ Default value for YYLTYPE.
+
+`YYMAXDEPTH'
+ Macro for specifying the maximum size of the parser stack. *Note
+ Stack Overflow::.
+
+`YYPARSE_PARAM'
+ Macro for specifying the name of a parameter that `yyparse' should
+ accept. *Note Calling Conventions for Pure Parsers: Pure Calling.
+
+`YYRECOVERING'
+ Macro whose value indicates whether the parser is recovering from a
+ syntax error. *Note Special Features for Use in Actions: Action
+ Features.
+
+`YYSTYPE'
+ Macro for the data type of semantic values; `int' by default.
+ *Note Data Types of Semantic Values: Value Type.
+
+`yychar'
+ External integer variable that contains the integer value of the
+ current look-ahead 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.
+
+`yyclearin'
+ Macro used in error-recovery rule actions. It clears the previous
+ look-ahead token. *Note Error Recovery::.
+
+`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 Debugging Your Parser: Debugging.
+
+`yyerrok'
+ Macro to cause parser to recover immediately to its normal mode
+ after a parse error. *Note Error Recovery::.
+
+`yyerror'
+ User-supplied function to be called by `yyparse' on error. The
+ function receives one argument, a pointer to a character string
+ containing an error message. *Note The Error Reporting Function
+ `yyerror': Error Reporting.
+
+`yylex'
+ User-supplied lexical analyzer function, called with no arguments
+ to get the next token. *Note The Lexical Analyzer Function
+ `yylex': Lexical.
+
+`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.
+
+`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 Positions of Tokens: Token
+ Positions.
+
+`yynerrs'
+ Global variable which Bison increments each time there is a parse
+ error. (In a pure parser, it is a local variable within
+ `yyparse'.) *Note The Error Reporting Function `yyerror': Error
+ Reporting.
+
+`yyparse'
+ The parser function produced by Bison; call this function to start
+ parsing. *Note The Parser Function `yyparse': Parser Function.
+
+`%debug'
+ Equip the parser for debugging. *Note Decl Summary::.
+
+`%defines'
+ Bison declaration to create a header file meant for the scanner.
+ *Note Decl Summary::.
+
+`%left'
+ Bison declaration to assign left associativity to token(s). *Note
+ Operator Precedence: Precedence Decl.
+
+`%no_lines'
+ Bison declaration to avoid generating `#line' directives in the
+ parser file. *Note Decl Summary::.
+
+`%nonassoc'
+ Bison declaration to assign non-associativity to token(s). *Note
+ Operator Precedence: Precedence Decl.
+
+`%prec'
+ Bison declaration to assign a precedence to a specific rule.
+ *Note Context-Dependent Precedence: Contextual Precedence.
+
+`%pure_parser'
+ Bison declaration to request a pure (reentrant) parser. *Note A
+ Pure (Reentrant) Parser: Pure Decl.
+
+`%right'
+ Bison declaration to assign right associativity to token(s).
+ *Note Operator Precedence: Precedence Decl.
+
+`%start'
+ Bison declaration to specify the start symbol. *Note The
+ Start-Symbol: Start Decl.
+
+`%token'
+ Bison declaration to declare token(s) without specifying
+ precedence. *Note Token Type Names: Token Decl.
+
+`%token_table'
+ Bison declaration to include a token name table in the parser file.
+ *Note Decl Summary::.
+
+`%type'
+ Bison declaration to declare nonterminals. *Note Nonterminal
+ Symbols: Type Decl.
+
+`%union'
+ Bison declaration to specify several possible data types for
+ semantic values. *Note The Collection of Value Types: Union Decl.
+
+ These are the punctuation and delimiters used in Bison input:
+
+`%%'
+ Delimiter used to separate the grammar rule section from the Bison
+ declarations section or the additional C code section. *Note The
+ Overall Layout of a Bison Grammar: Grammar Layout.
+
+`%{ %}'
+ All code listed between `%{' and `%}' is copied directly to the
+ output file uninterpreted. Such code forms the "C declarations"
+ section of the input file. *Note Outline of a Bison Grammar:
+ Grammar Outline.
+
+`/*...*/'
+ Comment delimiters, as in C.
+
+`:'
+ Separates a rule's result from its components. *Note Syntax of
+ Grammar Rules: Rules.
+
+`;'
+ Terminates a rule. *Note Syntax of Grammar Rules: Rules.
+
+`|'
+ Separates alternate rules for the same result nonterminal. *Note
+ Syntax of Grammar Rules: Rules.
+
\1f
File: bison.info, Node: Glossary, Next: Index, Prev: Table of Symbols, Up: Top
-@set UPDATED 9 August 2001
+@set UPDATED 10 August 2001
@set EDITION 1.28c
@set VERSION 1.28c
-@set UPDATED 9 August 2001
+@set UPDATED 10 August 2001
@set EDITION 1.28c
@set VERSION 1.28c
projects / bison.git / commitdiff
