[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %union foo bar baz and others { ... }
From: |
Paul Eggert |
Subject: |
Re: %union foo bar baz and others { ... } |
Date: |
19 Jan 2003 23:56:34 -0800 |
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.
- Re: Bison patch for POSIX and Yacc compatibility with %union, Akim Demaille, 2003/01/13
- Re: Bison patch for POSIX and Yacc compatibility with %union, Paul Eggert, 2003/01/13
- Re: POSIX_ME_HARDER (Was: Bison patch for POSIX and Yacc compatibility with %union), Akim Demaille, 2003/01/15
- Re: POSIX_ME_HARDER (Was: Bison patch for POSIX and Yacc compatibility with %union), Paul Eggert, 2003/01/16
- Re: %union foo bar baz and others { ... }, Akim Demaille, 2003/01/19
- Re: %union foo bar baz and others { ... },
Paul Eggert <=
- Re: %union foo bar baz and others { ... }, Akim Demaille, 2003/01/21
- Re: %union foo bar baz and others { ... }, Paul Eggert, 2003/01/22
- Re: %union foo bar baz and others { ... }, Akim Demaille, 2003/01/22
- Re: %union foo bar baz and others { ... }, Paul Eggert, 2003/01/22
- Re: ending ; (Was: POSIX_ME_HARDER), Akim Demaille, 2003/01/21
- Re: ending ; (Was: POSIX_ME_HARDER), Paul Eggert, 2003/01/22
- Re: Reserved name classes, Akim Demaille, 2003/01/21
- Re: Reserved name classes, Paul Eggert, 2003/01/22
- Re: Paul and I (Was: POSIX_ME_HARDER), Akim Demaille, 2003/01/22