[Top][All Lists]

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

Re: Reductions during Bison error handling

From: Hans Aberg
Subject: Re: Reductions during Bison error handling
Date: Wed, 22 May 2002 00:13:10 +0200

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

reply via email to

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