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 * 3and the next input token is a newline character, then the last three elements can be reduced to 15 via the rule:
expr: expr '*' expr;Following this reduction the stack contains just these three elements:
1 + 15At 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 (see section 3.1). This kind of parser is known in the literature as a bottom-up (or shift-reduce) parser.
Bisonc++'s sources contain much information about how this kind of parser was implemented. The theoretical foundation of the algorithm implemented in Bisonc++ can be found in Aho, Sethi and Ullman ()'s book Compilers.
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 parser's private data member
d_token
. However, this data member is not normally modified by member
functions not generated by Bisonc++. See section 6.5.1.
if
and if-else
statements, with a pair of rules like this:
if_stmt: IF '(' expr ')' stmt | IF '(' expr ')' stmt ELSE stmt ;Here we assume that
IF
and ELSE
are terminal symbols for specific
keywords, and that expr
and stmnt
are defined non-terminals.
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. Bisonc++ is designed to resolve these conflicts
by implementing a 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) if (y) then win(); else lose(); if (x) { if (y) then win(); else lose(); }But if the parser would perform a reduction whenever possible rather than a shift, the result would be to attach the else-clause to the outermost if-statement, making these two inputs equivalent:
if (x) if (y) then win(); else lose(); if (x) { if (y) win(); } 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 Bisonc++ accomplishes by implementing a shift rather than a reduce. This particular ambiguity was first encountered in the specifications of Algol 60 and is called the dangling else ambiguity.
To avoid warnings from Bisonc++ about predictable, legitimate shift/reduce
conflicts, use the %expect n
directive. There will be no warning as long
as the number of shift/reduce conflicts is exactly n
. See section
5.6.5.
The definition of if_stmt above is solely to blame for the conflict, but the
plain stmnt
rule, consisting of two recursive alternatives will of course
never be able to match actual input, since there's no way for the grammar to
eventually derive a sentence this way. Adding one non-recursive alternative is
enough to convert the grammar into one that does derive sentences. Here is
a complete Bisonc++ input file that actually manifests the conflict:
%token IF ELSE VAR %% stmt: VAR ';' | IF '(' VAR ')' stmt | IF '(' VAR ')' stmt ELSE stmt ;
1 - 2 * 3
' can be parsed in two different ways):
expr: expr '-' expr | expr '*' expr | expr '<' expr | '(' expr ')' ... ;Suppose the parser has seen the tokens `
1
', `-'
and `2
';
should it reduce them via the rule for the addition operator? It depends on
the next token. Of course, if the next token is `)', we must reduce;
shifting is invalid because no single rule can reduce the token sequence `-
2
)' or anything starting with that. But if the next token is `*
'
or `<
', we have a choice: either shifting or reduction would allow the
parse to complete, but with different results.
To decide which one Bisonc++ should do, we must consider the results. If
the next operator token op
is shifted, then it must be reduced first in
order to permit another opportunity to reduce the sum. The result is (in
effect) `1 - (2 op 3)
'. On the other hand, if the subtraction is reduced
before shifting op
, the result is `(1 - 2) op 3
'. Clearly, then, the
choice of shift or reduce should depend on the relative precedence of the
operators `-
' and op
: `*
' should be shifted first, but not
`<
'.
What about input such as `1 - 2 - 5
'; should this be `(1 - 2) - 5
' or
should it be `1 - (2 - 5)
'? For most operators we prefer the former, which
is called left association. The latter alternative, right association,
is desirable for, e.g., 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 `1 - 2
' and the look-ahead token is `-
': shifting
results in right-associativity.
%left
and %right
. Each such directive contains a list of
tokens, which are operators whose precedence and associativity is being
declared. The %left
directive makes all those operators left-associative
and the %right
directive makes them right-associative. A third alternative
is %nonassoc
, which declares that it is a syntax error to find the same
operator twice `in a row'. Actually, %nonassoc
is not currently (0.98.004)
punished that way by Bisonc++. Instead, %nonassoc
and %left
are
handled identically.
The relative precedence of different operators is controlled by the order in
which they are declared. The first %left
or %right
directive in the
file declares the operators whose precedence is lowest, the next such
directive declares the operators whose precedence is a little higher, and so
on.
%left '<' %left '-' %left '*'In a more complete example, which supports other operators as well, we would declare them in groups of equal precedence. For example, '
+
' is
declared with '-
':
%left '<' '>' '=' NE LE GE %left '+' '-' %left '*' '/'(Here
NE
and so on stand for the operators for `not equal' and so
on. We assume that these tokens are more than one character long and therefore
are represented by names, not character literals.)
Finally, the resolution of conflicts works by comparing the precedence of the
rule being considered with that of the look-ahead token. If the token's
precedence is higher, the choice is to shift. If the rule's precedence is
higher, the choice is to reduce. If they have equal precedence, the choice is
made based on the associativity of that precedence level. The verbose output
file made by `-V
' (see section 9 says how each conflict was
resolved.
Not all rules and not all tokens have precedence. If either the rule or the look-ahead token has no precedence, then the default is to shift.
The Bisonc++ precedence directives, %left, %right and %nonassoc, can only be used once for a given token; so a token has only one precedence declared in this way. For context-dependent precedence, you need to use an additional mechanism: the %prec modifier for rules.
The %prec modifier declares the precedence of a particular rule by specifying a terminal symbol whose precedence should be used for that rule. It's not necessary for that symbol to appear otherwise in the rule. The modifier's syntax is:
%prec terminal-symbol
and it is written after the components of the rule. Its effect is to assign the rule the precedence of terminal-symbol, overriding the precedence that would be deduced for it in the ordinary way. The altered rule precedence then affects how conflicts involving that rule are resolved (see section Operator Precedence).
Here is how %prec solves the problem of unary minus. First, declare a precedence for a fictitious terminal symbol named UMINUS. There are no tokens of this type, but the symbol serves to stand for its precedence:
... %left '+' '-' %left '*' %left UMINUS
Now the precedence of UMINUS can be used in specific rules:
exp: ... | exp '-' exp ... | '-' exp %prec UMINUS
parse()
is implemented using a finite-state
machine. The values pushed on the parser stack are not simply token type
codes; they represent the entire sequence of terminal and nonterminal symbols
at or near the top of the stack. The current state collects all the
information about previous input which is relevant to deciding what to do
next.
Each time a look-ahead token is read, the current parser state together with the current (not yet processed) token are looked up in a table. This table entry can say Shift the token. This also specifies a new parser state, which is then pushed onto the top of the parser stack. Or it can say Reduce using rule number n. This means that a certain number of tokens or groupings are taken off the top of the stack, and that the rule's grouping becomes the `next token' to be considered. That `next token' is then used in combination with the state then at the stack's top, to determine the next state to consider. This (next) state is then again pushed on the stack, and a new token is requested from the lexical scanner, and the process repeats itself.
There are two special situations the parsing algorithm must consider:
parse()
returns the value 0, indicating a successful
parsing.
For example, here is an erroneous attempt to define a sequence of zero or more word groupings: %stype char * %token WORD
%%
sequence: // empty { cout << "empty sequence\n"; } | maybeword | sequence WORD { cout << "added word " << $2 << endl; } ;
maybeword: // empty { cout << "empty maybeword\n"; } | WORD { cout << "single word " << $1 << endl; } ;
The error is an ambiguity: there is more than one way to parse a single word into a sequence. It could be reduced to a maybeword and then into a sequence via the second rule. Alternatively, nothing-at-all could be reduced into a sequence via the first rule, and this could be combined with the word using the third rule for sequence.
There is also more than one way to reduce nothing-at-all into a sequence. This can be done directly via the first rule, or indirectly via maybeword and then the second rule.
You might think that this is a distinction without a difference, because it does not change whether any particular input is valid or not. But it does affect which actions are run. One parsing order runs the second rule's action; the other runs the first rule's action and the third rule's action. In this example, the output of the program changes.
Bisonc++ resolves a reduce/reduce conflict by choosing to use the rule that appears first in the grammar, but it is very risky to rely on this. Every reduce/reduce conflict must be studied and usually eliminated. Here is the proper way to define sequence:
sequence: /* empty */ { printf ("empty sequence\n"); } | sequence word { printf ("added word %s\n", $2); } ;
Here is another common error that yields a reduce/reduce conflict:
sequence: /* empty */ | sequence words | sequence redirects ;
words: /* empty */ | words word ;
redirects:/* empty */ | redirects redirect ;
The intention here is to define a sequence which can contain either word or redirect groupings. The individual definitions of sequence, words and redirects are error-free, but the three together make a subtle ambiguity: even an empty input can be parsed in infinitely many ways!
Consider: nothing-at-all could be a words. Or it could be two words in a row, or three, or any number. It could equally well be a redirects, or two, or any number. Or it could be a words followed by three redirects and another words. And so on.
Here are two ways to correct these rules. First, to make it a single level of sequence:
sequence: /* empty */ | sequence word | sequence redirect ;
Second, to prevent either a words or a redirects from being empty:
sequence: /* empty */ | sequence words | sequence redirects ;
words: word | words word ;
redirects:redirect | redirects redirect ;
%token ID %% def: param_spec return_spec ',' ; param_spec: type | name_list ':' type ; return_spec: type | name ':' type ; type: ID ; name: ID ; name_list: name | name ',' name_list ;It would seem that this grammar can be parsed with only a single token of look-ahead: when a param_spec is being read, an
ID
is a name
if a
comma or colon follows, or a type
if another ID
follows. In other
words, this grammar is LR(1).
However, Bisonc++, like most parser generators, cannot actually handle all LR(1)
grammars. In this grammar, two contexts, that after an ID
at the beginning
of a param_spec
and likewise at the beginning of a return_spec
, are
similar enough that Bisonc++ assumes they are the same. They appear similar
because the same set of rules would be active--the rule for reducing to a name
and that for reducing to a type. Bisonc++ is unable to determine at that stage of
processing that the rules would require different look-ahead tokens in the two
contexts, so it makes a single parser state for them both. Combining the two
contexts causes a conflict later. In parser terminology, this occurrence means
that the grammar is not LALR(1).
In general, it is better to fix deficiencies than to document them. But this particular deficiency is intrinsically hard to fix; parser generators that can handle LR(1) grammars are hard to write and tend to produce parsers that are very large. In practice, Bisonc++ is more useful as it is now.
When the problem arises, you can often fix it by identifying the two parser
states that are being confused, and adding something to make them look
distinct. In the above example, adding one rule to return_spec
as follows
makes the problem go away:
%token BOGUS ... %% ... return_spec: type | name ':' type | ID BOGUS // This rule is never used. ;This corrects the problem because it introduces the possibility of an additional active rule in the context after the
ID
at the beginning of
return_spec
. This rule is not active in the corresponding context in a
param_spec
, so the two contexts receive distinct parser states. As long as
the token BOGUS
is never generated by the parser's member function
lex()
, the added rule cannot alter the way actual input is parsed.
In this particular example, there is another way to solve the problem: rewrite
the rule for return_spec
to use ID
directly instead of via name. This
also causes the two confusing contexts to have different sets of active rules,
because the one for return_spec
activates the altered rule for
return_spec
rather than the one for name.
param_spec: type | name_list ':' type ; return_spec: type | ID ':' type ;