>You should have gotten an ambiguous grammar. Then Bison still
>produces a runnable parser by choosing: in the case of reduce/reduce [sic]
>conflicts, shift over reduce, and in the case of reduce/reduce
>conflicts, the first occurring reduce in the .y grammar.
Yes, the grammar is indeed ambiguous, resulting in a shift/reduce
conflict in state 2. The conflict is realized when the look-ahead
token in that state is the end-of-file token. The conflict is then
resolved (as you dewscribe) by shifting, which leads to successful
termination. All of this makes sense, but is irrelevant to my
question, since the conflict is not realized in the execution of
interest. In this execution, when we enter state 2, the look-ahead
token is 'b', which is not shiftable. The output file suggests a
reduction via rule 3 at this point:
state 2
a -> p . (rule 3)
$ go to state 4
$ [reduce using rule 3 (a)]
$default reduce using rule 3 (a)
Indeed, this is what I would have predicted. But instead, the parser
terminates with an error. How did Bison decide to prescribe this
action, and why does it not appear in the output file?
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
