Re: Reductions during Bison error handling

[Richard Stallman]

    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.

Yes, or at least we should try.

                                                       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.

This sort of thing happens all the time with undocumented features in
(say) Windows.  People use trial and error and get something that works.
We certainly must not assume nobody depends on this merely because
it isn't documented.

There are other possible reasons which could be persuasive if they are
applicable.  For instance, if the current behavior is to fail where it
ought to succeed, it is unlikely anyone would depend on that because
it is unlikely to be of use for any real task.  If it reports an
error but at the wrong place, that can't be useful.

                                                                 Can you,
    in fact, describe the current behavior in Bison-user-level terms?

No, but that proves nothing--I have forgotten all these details.

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

IF it is possible for existing programs to depend on the current
behavior, that is too risky.  If we can be sure no existing programs
depend on the current behavior, we don't need to support both modes.