[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Controlling the effects of precedence declarations

From: Paul Hilfinger
Subject: Re: Controlling the effects of precedence declarations
Date: Mon, 12 May 2003 19:13:06 -0700

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]