Re: %union foo bar baz and others { ... }

[Paul Eggert]

Akim Demaille <address@hidden> writes:

> Hm, I thought I had already made clear that C++ wants the tag and the
> type to be equal.

Sorry, what does that mean?  (I don't know C++ well enough.)
By default, Bison 1.875 uses the following pattern:

  typedef union YYSTYPE { ... } YYSTYPE;

This declares YYSTYPE twice, once as a union tag and once as a
typedef, but in C these are distinct namespaces so it's OK.  Is this
also valid C++, or is it invalid because it attempts to declare
YYSTYPE twice in the same namespace?  Or do all the C++ users put
`extern "C"' around this typedef, and that makes it valid C++ anyway?

This pattern is new to Bison 1.875.  Bison 1.75 and earlier did this:

  typedef union { ... } yystype;
  #define YYSTYPE yystype

The change to `typedef ... YYSTYPE' was for POSIX conformance.  The
change to `union YYSTYPE' was my own idea, because I thought it would
help pacify users that wanted a union tag for some reason, and my
vague understanding from David Durham's "quick Bison Q" emails is that
C++ users sometimes fall into this camp because they want the union to
be a friend of a C++ class.

If that's all they need, can these users simply use the Bison 1.875
pattern, and make "union YYSTYPE" a friend of a C++ class?  If so,
they won't need the "%union foo {...}" extension, and I'll happily
write, test and install a patch to Bison to remove that extension.  As
far as I recall, it's only C++ users that have requested that feature.


> The only extension have in mind in this area is that multiple %union
> should be allowed.  Add a form of inclusion, and you end up with a
> form of modules for grammars.

In that case you need names for the different unions, no?  But I sense
that you intend the names should be those of the modules, and won't
belong to the unions themselves.  I am a bit at sea here, since I
don't fully understand the potential problems here, but I don't think
my cluelessness matters much.


> Lemon had it right: there is no reason for the user to know the name
> of the fields.  But that's not important.

Not for now, yes; we're just trying to get 2.0 out the door.
It might be nice to swipe ideas from Lemon later.