>It's not much, but I think it is a little clearer at least. Here's how >mine looks: > >state 2 > > 0 $accept: p . $end > 3 a: p . [$end] > > $end shift, and go to state 4 > > $end [reduce using rule 3 (a)] > >As Hans said, the shift (for the Bison-generated rule 0) is chosen, and so >the reduce (rule 3 with lookahead) can't even be encoded in the LALR(1) >action table. The reduce is printed above just to show the conflict. > >Joel
It would appear that my Bison has a bug, not in the parser generator itself, but in the generation of the "output" file. The output above is more suggestive of the observed bahavior than the output that I get. The line > 3 a: p . [$end] is the interesting one. I suppose it's saying that the rule should not be reduced unless the lookahead token is $end. This must be what you mean by "lookahead information". I do not understand how Bison derives this information. Can anyone explain this aspect of the algorithm or tell me how I can learn about it? _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
