[Top][All Lists]

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

Re: Reductions during Bison error handling

From: Paul Hilfinger
Subject: Re: Reductions during Bison error handling
Date: Mon, 20 May 2002 15:27:23 -0700

 > We have to be very careful about incompatible changes here.  Unless it
 > is absolutely clear that the current behavior is a bug, unless it is
 > absolutely clear that nobody would try to rely on it, we must assume
 > there are dozens of existing parsers that do rely on it.  We do not
 > dare break them, not by default.

I agree with this as a general principle.  However, in this particular
case, Bison does not agree with its documentation.  If we keep the
current behavior, we really ought to document it.  Given how difficult
LALR(1) parser internal behavior is to understand, I find it a little
unlikely that there can be any significant reliance on the obscure
places where current behavior differs from that documented.  Can you,
in fact, describe the current behavior in Bison-user-level terms?  I'm
not sure I can, as a matter of fact, which makes me think that the
current behavior is a subtle, never-noticed bug.  

This impression is increased now that I've looked at Sun's yacc and
seen that it correctly implements the spec documented in the bison

 > Now, what we could do is add a command (perhaps `%errorfix') that says
 > to use the corrected error behavior.  This way, existing parsers won't
 > change, but the improved behavior is available for new or updated
 > parsers.

Under the circumstances, I would be inclined instead to have a command
`%olderror' or `%traditionalerror' (or `%brokenerror' (:->)) to go in
the other direction.

On the other hand, if we were to modify Bison NOT to use default
reductions at all (that is, to make error the default reduction), as
has been mooted in this thread, we would certainly want an explicit,
positive-sense directive for that.

Paul Hilfinger

reply via email to

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