[Top][All Lists]

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

Re: Controlling the effects of precedence declarations

From: Frank Heckenbach
Subject: Re: Controlling the effects of precedence declarations
Date: Wed, 14 May 2003 05:04:49 +0200

Paul Hilfinger wrote:

> 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.

I guess the same is true of recursive rules vs. star-notation etc.
In my experience, initially BNF and similar grammars looked a bit
strange, but once I'd become used to them, I didn't find them any
harder to read than the "natural" form (in both cases).

> 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 never claimed it's superior. Both ways have pros and cons. I just
happen to prefer this way.

> > 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?

A single one obviously doesn't (when using a special precedence
token for the rule). But a few of them could. I can't give a
concrete example, since I haven't had such a problem yet (at least I
hope so, since bison wouldn't tell me otherwise ...).

I imagine it would occur quite rarely (but in a way the rare bugs
are the most difficult to find), probably when the same tokens are
used in different contexts (in C perhaps tokens such as `{}', `()',
`,', `while', `:') and have precedence in one of the contexts (which
is probably not the case for those tokens in C).


Frank Heckenbach, address@hidden
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

reply via email to

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