Re: Dubious features

[Paul Eggert]

Akim Demaille <address@hidden> writes:

> This feature was removed from several versions of Bison, restored
> by you on Christmas Eve 2002.  In the meantime, no one complained.

Actually they did complain; that's why I changed it back.

Here's the complaint that prompted me to restore the feature:
<http://lists.gnu.org/archive/html/bug-bison/2002-12/msg00004.html>.
According to
<http://lists.gnu.org/archive/html/bison-patches/2002-12/msg00015.html>,
others also complained.

The Bison versions that you're referring to (namely, 1.50 and 1.75)
were widely avoided due to backward-compatibility problems.  Even
today, Debian GNU/Linux stable ships a "bison-1.35" package for people
who got bitten by so many of those problems that they still don't want
to upgrade.  We should not use the existence of 1.50 and 1.75 to
justify breaking compatibility with Yacc; on the contrary, 1.50 and
1.75 provide powerful arguments (which are still vivid in my memory,
at least :-) for preserving backward compatibility.

> I don't think that [OpenBSD] counts.

I don't see why not.  The implementation in OpenBSD is quite a bit
different from that of today's Bison.  At this point it's pretty much
an independent implementation (partly because the OpenBSD folks hate
GNU-licensed code).

> I care about compatibility, but I'm more interest in gaining new
> users thanks to new features rather that keeping users of old stuff.

Sorry, I don't see the connection.  What does the proposed change have
to do with adding new features, if you consider the Bison user's point
of view?

> And in the present case I'm not asking for the removal of the
> feature, but to make it what it should be: either rational or
> context free.

Sorry, I don't understand what you mean by "rational" and "context
free"?  Are you talking about internal implementation details?  I'm
not particularly worried about the Bison implementation here; it's the
user-visible behavior that concerns me.

Let's put it this way.  The proposed change is incomplete, in that
we'd have to add something like the following to the documentation.

  However, "{" cannot appear within comments that appear between the
  keyword %union and the immediately following "{".  For example,
  "%union /* { } */ { int val; }" is not valid.

This would add a special case to the documentation, and to the user's
model of how comments work in Bison grammars, for no reason that is
apparent to the user's point of view.

People naturally expect to be able to put as many comments as they
like before or after any token.  We shouldn't undermine that
expectation by having an obscure special case for "{" in comments
between %union and "{".