Future/bison
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/bison.git synced 2026-03-09 20:33:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

Regen.

Browse Source
This commit is contained in:
Akim Demaille
2001-08-10 09:35:01 +00:00
parent 6f42a3e682
commit a940e84e29
6 changed files with 401 additions and 364 deletions
Download Patch File Download Diff File Expand all files Collapse all files

102
doc/bison.info
View File

@@ -33,8 +33,8 @@ Indirect:
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

Tag Table:
(Indirect)
@@ -86,54 +86,54 @@ Node: Actions95726
Node: Action Types98511
Node: Mid-Rule Actions99814
Node: Locations105384
Node: Location Type106049
Node: Actions and Locations106607
Node: Location Default Action107771
Node: Declarations108978
Node: Token Decl110297
Node: Precedence Decl112310
Node: Union Decl113861
Node: Type Decl114705
Node: Expect Decl115611
Node: Start Decl117157
Node: Pure Decl117535
Node: Decl Summary119212
Node: Multiple Parsers124595
Node: Interface126089
Node: Parser Function126961
Node: Lexical127796
Node: Calling Convention129202
Node: Token Values131973
Node: Token Positions133122
Node: Pure Calling134007
Node: Error Reporting136939
Node: Action Features139061
Node: Algorithm142356
Node: Look-Ahead144649
Node: Shift/Reduce146781
Node: Precedence149693
Node: Why Precedence150344
Node: Using Precedence152209
Node: Precedence Examples153177
Node: How Precedence153878
Node: Contextual Precedence155027
Node: Parser States156818
Node: Reduce/Reduce158061
Node: Mystery Conflicts161622
Node: Stack Overflow165008
Node: Error Recovery166381
Node: Context Dependency171517
Node: Semantic Tokens172365
Node: Lexical Tie-ins175382
Node: Tie-in Recovery176930
Node: Debugging179102
Node: Invocation182403
Node: Bison Options183655
Node: Environment Variables187089
Node: Option Cross Key187937
Node: VMS Invocation188781
Node: Table of Symbols189565
Node: Glossary196958
Node: Index203248
Node: Location Type106032
Node: Actions and Locations106590
Node: Location Default Action108746
Node: Declarations110209
Node: Token Decl111528
Node: Precedence Decl113541
Node: Union Decl115092
Node: Type Decl115936
Node: Expect Decl116842
Node: Start Decl118388
Node: Pure Decl118766
Node: Decl Summary120443
Node: Multiple Parsers125826
Node: Interface127320
Node: Parser Function128192
Node: Lexical129027
Node: Calling Convention130433
Node: Token Values133204
Node: Token Positions134353
Node: Pure Calling135238
Node: Error Reporting138170
Node: Action Features140292
Node: Algorithm143587
Node: Look-Ahead145880
Node: Shift/Reduce148012
Node: Precedence150924
Node: Why Precedence151575
Node: Using Precedence153440
Node: Precedence Examples154408
Node: How Precedence155109
Node: Contextual Precedence156258
Node: Parser States158049
Node: Reduce/Reduce159292
Node: Mystery Conflicts162853
Node: Stack Overflow166239
Node: Error Recovery167612
Node: Context Dependency172748
Node: Semantic Tokens173596
Node: Lexical Tie-ins176613
Node: Tie-in Recovery178161
Node: Debugging180333
Node: Invocation183634
Node: Bison Options184886
Node: Environment Variables188320
Node: Option Cross Key189168
Node: VMS Invocation190012
Node: Table of Symbols190796
Node: Glossary198189
Node: Index204479

End Tag Table

162
doc/bison.info-3
View File

@@ -165,7 +165,7 @@ Tracking Locations
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.
@@ -213,19 +213,47 @@ elements being matched. The location of the Nth component of the right
hand side is `@N', while the location of the left hand side grouping is
`@$'.
Here is a 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);
}
}

File: bison.info, Node: Location Default Action, Prev: Actions and Locations, Up: Locations
@@ -235,26 +263,35 @@ Default Action for Locations
Actually, actions are not the best place to compute locations. Since
locations are much more general than semantic values, there is room in
the output parser to 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.
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.
Most of the time, this macro is general enough to suppress location
dedicated code from semantic actions.
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:
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.
#define YYLLOC_DEFAULT(Current, Last) \
Current.last_line = Last.last_line; \
Current.last_column = Last.last_column;
By default, it is defined this way:
Most of the time, the default action for locations is general enough to
suppress location dedicated code from most actions.
#define YYLLOC_DEFAULT(Current, Rhs, N) \
Current.last_line = Rhs[N].last_line; \
Current.last_column = Rhs[N].last_column;
When defining `YYLLOC_DEFAULT', you should consider that:
* All arguments are free of side-effects. However, only the first
one (the result) should be modified by `YYLLOC_DEFAULT'.
* 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.

File: bison.info, Node: Declarations, Next: Multiple Parsers, Prev: Locations, Up: Grammar File
@@ -1241,82 +1278,3 @@ sequence.
The current look-ahead token is stored in the variable `yychar'.
*Note Special Features for Use in Actions: Action Features.

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
;

288
doc/bison.info-4
View File

@@ -28,6 +28,85 @@ License", "Conditions for Using Bison" and this permission notice may be
included in translations approved by the Free Software Foundation
instead of in the original English.

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
;

File: bison.info, Node: Precedence, Next: Contextual Precedence, Prev: Shift/Reduce, Up: Algorithm
@@ -1058,212 +1137,3 @@ is equivalent to the following command under POSIX.
In the above example, the output file would instead be named
`foo_tab.c'.

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.

209
doc/bison.info-5
View File

@@ -28,6 +28,215 @@ License", "Conditions for Using Bison" and this permission notice may be
included in translations approved by the Free Software Foundation
instead of in the original English.

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.

File: bison.info, Node: Glossary, Next: Index, Prev: Table of Symbols, Up: Top

2
doc/stamp-vti
View File

@@ -1,3 +1,3 @@
@set UPDATED 9 August 2001
@set UPDATED 10 August 2001
@set EDITION 1.28c
@set VERSION 1.28c

2
doc/version.texi
View File

@@ -1,3 +1,3 @@
@set UPDATED 9 August 2001
@set UPDATED 10 August 2001
@set EDITION 1.28c
@set VERSION 1.28c