29 |
instead of in the original English. |
instead of in the original English. |
30 |
|
|
31 |
|
|
32 |
|
File: bison.info, Node: Value Type, Next: Multiple Types, Up: Semantics |
33 |
|
|
34 |
|
Data Types of Semantic Values |
35 |
|
----------------------------- |
36 |
|
|
37 |
|
In a simple program it may be sufficient to use the same data type |
38 |
|
for the semantic values of all language constructs. This was true in |
39 |
|
the RPN and infix calculator examples (*note Reverse Polish Notation |
40 |
|
Calculator: RPN Calc.). |
41 |
|
|
42 |
|
Bison's default is to use type `int' for all semantic values. To |
43 |
|
specify some other type, define `YYSTYPE' as a macro, like this: |
44 |
|
|
45 |
|
#define YYSTYPE double |
46 |
|
|
47 |
|
This macro definition must go in the C declarations section of the |
48 |
|
grammar file (*note Outline of a Bison Grammar: Grammar Outline.). |
49 |
|
|
50 |
|
|
51 |
|
File: bison.info, Node: Multiple Types, Next: Actions, Prev: Value Type, Up: Semantics |
52 |
|
|
53 |
|
More Than One Value Type |
54 |
|
------------------------ |
55 |
|
|
56 |
|
In most programs, you will need different data types for different |
57 |
|
kinds of tokens and groupings. For example, a numeric constant may |
58 |
|
need type `int' or `long', while a string constant needs type `char *', |
59 |
|
and an identifier might need a pointer to an entry in the symbol table. |
60 |
|
|
61 |
|
To use more than one data type for semantic values in one parser, |
62 |
|
Bison requires you to do two things: |
63 |
|
|
64 |
|
* Specify the entire collection of possible data types, with the |
65 |
|
`%union' Bison declaration (*note The Collection of Value Types: |
66 |
|
Union Decl.). |
67 |
|
|
68 |
|
* Choose one of those types for each symbol (terminal or |
69 |
|
nonterminal) for which semantic values are used. This is done for |
70 |
|
tokens with the `%token' Bison declaration (*note Token Type |
71 |
|
Names: Token Decl.) and for groupings with the `%type' Bison |
72 |
|
declaration (*note Nonterminal Symbols: Type Decl.). |
73 |
|
|
74 |
|
|
75 |
|
File: bison.info, Node: Actions, Next: Action Types, Prev: Multiple Types, Up: Semantics |
76 |
|
|
77 |
|
Actions |
78 |
|
------- |
79 |
|
|
80 |
|
An action accompanies a syntactic rule and contains C code to be |
81 |
|
executed each time an instance of that rule is recognized. The task of |
82 |
|
most actions is to compute a semantic value for the grouping built by |
83 |
|
the rule from the semantic values associated with tokens or smaller |
84 |
|
groupings. |
85 |
|
|
86 |
|
An action consists of C statements surrounded by braces, much like a |
87 |
|
compound statement in C. It can be placed at any position in the rule; |
88 |
|
it is executed at that position. Most rules have just one action at |
89 |
|
the end of the rule, following all the components. Actions in the |
90 |
|
middle of a rule are tricky and used only for special purposes (*note |
91 |
|
Actions in Mid-Rule: Mid-Rule Actions.). |
92 |
|
|
93 |
|
The C code in an action can refer to the semantic values of the |
94 |
|
components matched by the rule with the construct `$N', which stands for |
95 |
|
the value of the Nth component. The semantic value for the grouping |
96 |
|
being constructed is `$$'. (Bison translates both of these constructs |
97 |
|
into array element references when it copies the actions into the parser |
98 |
|
file.) |
99 |
|
|
100 |
|
Here is a typical example: |
101 |
|
|
102 |
|
exp: ... |
103 |
|
| exp '+' exp |
104 |
|
{ $$ = $1 + $3; } |
105 |
|
|
106 |
|
This rule constructs an `exp' from two smaller `exp' groupings |
107 |
|
connected by a plus-sign token. In the action, `$1' and `$3' refer to |
108 |
|
the semantic values of the two component `exp' groupings, which are the |
109 |
|
first and third symbols on the right hand side of the rule. The sum is |
110 |
|
stored into `$$' so that it becomes the semantic value of the |
111 |
|
addition-expression just recognized by the rule. If there were a |
112 |
|
useful semantic value associated with the `+' token, it could be |
113 |
|
referred to as `$2'. |
114 |
|
|
115 |
|
If you don't specify an action for a rule, Bison supplies a default: |
116 |
|
`$$ = $1'. Thus, the value of the first symbol in the rule becomes the |
117 |
|
value of the whole rule. Of course, the default rule is valid only if |
118 |
|
the two data types match. There is no meaningful default action for an |
119 |
|
empty rule; every empty rule must have an explicit action unless the |
120 |
|
rule's value does not matter. |
121 |
|
|
122 |
|
`$N' with N zero or negative is allowed for reference to tokens and |
123 |
|
groupings on the stack _before_ those that match the current rule. |
124 |
|
This is a very risky practice, and to use it reliably you must be |
125 |
|
certain of the context in which the rule is applied. Here is a case in |
126 |
|
which you can use this reliably: |
127 |
|
|
128 |
|
foo: expr bar '+' expr { ... } |
129 |
|
| expr bar '-' expr { ... } |
130 |
|
; |
131 |
|
|
132 |
|
bar: /* empty */ |
133 |
|
{ previous_expr = $0; } |
134 |
|
; |
135 |
|
|
136 |
|
As long as `bar' is used only in the fashion shown here, `$0' always |
137 |
|
refers to the `expr' which precedes `bar' in the definition of `foo'. |
138 |
|
|
139 |
|
|
140 |
|
File: bison.info, Node: Action Types, Next: Mid-Rule Actions, Prev: Actions, Up: Semantics |
141 |
|
|
142 |
|
Data Types of Values in Actions |
143 |
|
------------------------------- |
144 |
|
|
145 |
|
If you have chosen a single data type for semantic values, the `$$' |
146 |
|
and `$N' constructs always have that data type. |
147 |
|
|
148 |
|
If you have used `%union' to specify a variety of data types, then |
149 |
|
you must declare a choice among these types for each terminal or |
150 |
|
nonterminal symbol that can have a semantic value. Then each time you |
151 |
|
use `$$' or `$N', its data type is determined by which symbol it refers |
152 |
|
to in the rule. In this example, |
153 |
|
|
154 |
|
exp: ... |
155 |
|
| exp '+' exp |
156 |
|
{ $$ = $1 + $3; } |
157 |
|
|
158 |
|
`$1' and `$3' refer to instances of `exp', so they all have the data |
159 |
|
type declared for the nonterminal symbol `exp'. If `$2' were used, it |
160 |
|
would have the data type declared for the terminal symbol `'+'', |
161 |
|
whatever that might be. |
162 |
|
|
163 |
|
Alternatively, you can specify the data type when you refer to the |
164 |
|
value, by inserting `<TYPE>' after the `$' at the beginning of the |
165 |
|
reference. For example, if you have defined types as shown here: |
166 |
|
|
167 |
|
%union { |
168 |
|
int itype; |
169 |
|
double dtype; |
170 |
|
} |
171 |
|
|
172 |
|
then you can write `$<itype>1' to refer to the first subunit of the |
173 |
|
rule as an integer, or `$<dtype>1' to refer to it as a double. |
174 |
|
|
175 |
|
|
176 |
File: bison.info, Node: Mid-Rule Actions, Prev: Action Types, Up: Semantics |
File: bison.info, Node: Mid-Rule Actions, Prev: Action Types, Up: Semantics |
177 |
|
|
178 |
Actions in Mid-Rule |
Actions in Mid-Rule |
1315 |
textual position of the Nth component of the current rule. *Note |
textual position of the Nth component of the current rule. *Note |
1316 |
Tracking Locations: Locations. |
Tracking Locations: Locations. |
1317 |
|
|
|
|
|
|
File: bison.info, Node: Algorithm, Next: Error Recovery, Prev: Interface, Up: Top |
|
|
|
|
|
The Bison Parser Algorithm |
|
|
************************** |
|
|
|
|
|
As Bison reads tokens, it pushes them onto a stack along with their |
|
|
semantic values. The stack is called the "parser stack". Pushing a |
|
|
token is traditionally called "shifting". |
|
|
|
|
|
For example, suppose the infix calculator has read `1 + 5 *', with a |
|
|
`3' to come. The stack will have four elements, one for each token |
|
|
that was shifted. |
|
|
|
|
|
But the stack does not always have an element for each token read. |
|
|
When the last N tokens and groupings shifted match the components of a |
|
|
grammar rule, they can be combined according to that rule. This is |
|
|
called "reduction". Those tokens and groupings are replaced on the |
|
|
stack by a single grouping whose symbol is the result (left hand side) |
|
|
of that rule. Running the rule's action is part of the process of |
|
|
reduction, because this is what computes the semantic value of the |
|
|
resulting grouping. |
|
|
|
|
|
For example, if the infix calculator's parser stack contains this: |
|
|
|
|
|
1 + 5 * 3 |
|
|
|
|
|
and the next input token is a newline character, then the last three |
|
|
elements can be reduced to 15 via the rule: |
|
|
|
|
|
expr: expr '*' expr; |
|
|
|
|
|
Then the stack contains just these three elements: |
|
|
|
|
|
1 + 15 |
|
|
|
|
|
At this point, another reduction can be made, resulting in the single |
|
|
value 16. Then the newline token can be shifted. |
|
|
|
|
|
The parser tries, by shifts and reductions, to reduce the entire |
|
|
input down to a single grouping whose symbol is the grammar's |
|
|
start-symbol (*note Languages and Context-Free Grammars: Language and |
|
|
Grammar.). |
|
|
|
|
|
This kind of parser is known in the literature as a bottom-up parser. |
|
|
|
|
|
* Menu: |
|
|
|
|
|
* Look-Ahead:: Parser looks one token ahead when deciding what to do. |
|
|
* Shift/Reduce:: Conflicts: when either shifting or reduction is valid. |
|
|
* Precedence:: Operator precedence works by resolving conflicts. |
|
|
* Contextual Precedence:: When an operator's precedence depends on context. |
|
|
* Parser States:: The parser is a finite-state-machine with stack. |
|
|
* Reduce/Reduce:: When two rules are applicable in the same situation. |
|
|
* Mystery Conflicts:: Reduce/reduce conflicts that look unjustified. |
|
|
* Stack Overflow:: What happens when stack gets full. How to avoid it. |
|
|
|
|
|
|
|
|
File: bison.info, Node: Look-Ahead, Next: Shift/Reduce, Up: Algorithm |
|
|
|
|
|
Look-Ahead Tokens |
|
|
================= |
|
|
|
|
|
The Bison parser does _not_ always reduce immediately as soon as the |
|
|
last N tokens and groupings match a rule. This is because such a |
|
|
simple strategy is inadequate to handle most languages. Instead, when a |
|
|
reduction is possible, the parser sometimes "looks ahead" at the next |
|
|
token in order to decide what to do. |
|
|
|
|
|
When a token is read, it is not immediately shifted; first it |
|
|
becomes the "look-ahead token", which is not on the stack. Now the |
|
|
parser can perform one or more reductions of tokens and groupings on |
|
|
the stack, while the look-ahead token remains off to the side. When no |
|
|
more reductions should take place, the look-ahead token is shifted onto |
|
|
the stack. This does not mean that all possible reductions have been |
|
|
done; depending on the token type of the look-ahead token, some rules |
|
|
may choose to delay their application. |
|
|
|
|
|
Here is a simple case where look-ahead is needed. These three rules |
|
|
define expressions which contain binary addition operators and postfix |
|
|
unary factorial operators (`!'), and allow parentheses for grouping. |
|
|
|
|
|
expr: term '+' expr |
|
|
| term |
|
|
; |
|
|
|
|
|
term: '(' expr ')' |
|
|
| term '!' |
|
|
| NUMBER |
|
|
; |
|
|
|
|
|
Suppose that the tokens `1 + 2' have been read and shifted; what |
|
|
should be done? If the following token is `)', then the first three |
|
|
tokens must be reduced to form an `expr'. This is the only valid |
|
|
course, because shifting the `)' would produce a sequence of symbols |
|
|
`term ')'', and no rule allows this. |
|
|
|
|
|
If the following token is `!', then it must be shifted immediately so |
|
|
that `2 !' can be reduced to make a `term'. If instead the parser were |
|
|
to reduce before shifting, `1 + 2' would become an `expr'. It would |
|
|
then be impossible to shift the `!' because doing so would produce on |
|
|
the stack the sequence of symbols `expr '!''. No rule allows that |
|
|
sequence. |
|
|
|
|
|
The current look-ahead token is stored in the variable `yychar'. |
|
|
*Note Special Features for Use in Actions: Action Features. |
|
|
|
|