Re: Reductions during Bison error handling

[Hans Aberg]

At 13:12 -0600 2002/05/21, Richard Stallman wrote:
>                                                      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.

I think one use to distinguish between supported features and unsupported
features: The supported features are those that the user can rely on will
continue to exist in the upgrades.

The Bison manual should clearly indicate what it considers supported
features and what is not.

A program relying on an unsupported Bison feature, perhaps undocumented,
discovered by trial and error or reading the sources or whatever, and
breaks when Bison is updated must expect to be rewritten.

As for error recovery, the Bison manual should pin down whatever is
supported; then that should be implemented. When pinning down what should
be supported, it is of course wise to consider past support, POSIX, other
Yacc versions, what is prudent for the Bison future, etc.

  Hans Aberg