Re: Controlling the effects of precedence declarations

[Paul Hilfinger]

For me, the overwhelming argument in favor of using precedence
declarations is that it makes the Bison (Yacc) description look like
the REAL description (i.e., the one in my head---the one that I would
really prefer to compare my computer-readable grammar description to).
My REAL description is something like, "The following are binary
operators: ....  In cases where the grouping is ambiguous, resolve in
such-and-such a manner."  Nobody I've met actually internalizes a
grammar in the hierarchy-of-nonterminals fashion.  The latter is
simply an artificial device to allow one to describe one's intended
syntax in formally pure BNF; there is no reason to expect such a
description to be easily digested by humans.

In general, any notation that makes it easier for me to check my
intended meaning against what I actually write is a great help.

 >   expr: '-' expr { $$ = -$2; };
 > 
 > Bison just accepts this and assigns the rule the same precedence as
 > the binary minus. This may or may not be what you intended. ...
 > [Bison] does not even tell you that there is a
 > conflict which is resolved this way (unless you check the verbose
 > logs).

Yes, and if you should accidentally write

     term : factor 
          | factor '*' factor
          | factor '/' factor
          ;

you will see no indication of your error even in the verbose logs!
In general, it does not suffice to say "Method X allows of
such-and-such a characteristic error" to demonstrate the superiority
of Method Y.

> I think the second of my suggestions (no default precedence for
> rules) is probably rather easy to implement. 

Probably, but now I'm curious.  It seems to me that with your Bison
programming style, there would be very few productions or terminals
assigned a precedence in any case, so it would surprise me greatly to
see more than a trivial number of "silent" errors creep in as a
result.  Do you actually find that introduction of a single precedence
declaration to handle an isolated dangling-qux problem causes
uncaught, difficult-to-track-down errors?

Paul Hilfinger