Re: %union ... {

[Akim Demaille]

>>> "Paul" == Paul Eggert <address@hidden> writes:

 > 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.

Thanks for the pointers (and reminders).  But I don't agree with your
analysis here: the complaint is to have a similar feature, not this
syntax.  My grief is against the syntax.  I would prefer by far to
accept an identifier here.

 > The Bison versions that you're referring to (namely, 1.50 and 1.75)
 > were widely avoided due to backward-compatibility problems.

Agreed.



 >> 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.

Last time I read its code (couple of years ago, agreed), the parser
was still the same.

 > At this point it's pretty much an independent implementation
 > (partly because the OpenBSD folks hate GNU-licensed code).

Agreed, but I was referring to the common ancestor byacc and bison
had.  They both inherited its parser, together with this "feature".


 >> 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?

I was referring to the fact that the whole machinery that was
implemented in the scanner was precisely prompted by this troublesome
%union.  As a result, using BRACED_CODE elsewhere became much harder,
which defeats the whole point of using a Bison grammar.


 >> 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?

Not exact, although arguably you could strip this down to
implementation details since rational languages are context-free
languages.

To re-state my position, I'm dislike the *syntax* of this feature
because it is neither lexical (i.e., a plain regexp), nor syntactic
(i.e., a rule in the grammar).

As a result, as a "feature", we accept weird input such as

   %union "{" {

we reject things like

   %union MACRO_THAT_THROWS_AWAY_ITS_ARGUMENT({) {

and fail to report unclosed parens in

  %union PREFIX(stype {


So to my eyes, as it stands today the syntax of the feature is
ill-designed.  If we want to make it wide opened to weird stuff, then
let's make it lexical, and that's my proposal.  Honestly, I dislike
this very much, first because it's ugly, and second because I fail to
see how it would scale to other language.  The other possibility, the
one I prefer, is to make it syntactic but more restricted: accept a
single optional ID in the grammar (then of course we have no problems
with comments).

*If* someone, someday, comes with a bigger need, then let's find a
syntax that fits ours, say

       %union-tag %{ My big meaningful tag %};
       %union { int foo; };