Re: Why Bison prefer reduce to shift in dangling else?

[Hans Aberg]

At 10:54 +0100 2003/02/26, Akim Demaille wrote:
> Hans> Bison prefers shift over reduce (as in the Bison manual
> Hans> sec. 5.2). So this is probably a misunderstanding: So just
> Hans> forgetting about it will give the right parsing.
>
> Hans> But it is better to use %nonassoc, as the grammr then becomes
> Hans> fully specified.
>
>I think neither is right, one just want %prec, something that would
>leave a conflict if associativity information appears to be needed at
>bison time, vs. %nonassoc which is run time only.

I am not sure what you are saying here: %nonassoc, %left and %right define
token precedences which Bison resolves completely statically at its compile
time by deciding whether certain states should shift or reduce on certain
lookahead tokens. -- Just look into the .output file to see which static
shift/reduce choices are made.

The advantage of this precedence approach is that somebody wrote down a
definition of grammars with precedences. So if that precedence approach is
used, it should probably be portable when changing parsing algorithms.

There is no good way to implement a dynamic precedence system into Bison,
it seems (in the sense that Bison conveniently supports it). I am working
on that right now for a language on my own (a mathematical proof
verification system based on metalogic rather than on logic as is usually
done). This is a more general precedence system for multicomponent
operators. This leads to essentially LR(n) states consisting of items where
some extra precedence information is added.

If you use %prec, then for that to portable between parsing algorithms,
then perhaps the rules of a grammar must be defined to be a list and not a
set as is traditionally done.

-- Perhaps you should post an example of using %prec and dangling "else" as
I have not seen this in the Bison groups, and nor is it in the manual, I
think.

  Hans Aberg