[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %union foo bar baz and others { ... }
From: |
Akim Demaille |
Subject: |
Re: %union foo bar baz and others { ... } |
Date: |
Sun, 19 Jan 2003 15:30:56 +0100 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) |
Paul> Akim Demaille <address@hidden> writes:
>> The net result is that the sources are atrocious, error prone,
>> intricate, while The Right Thing was elegant and did not hamper new
>> extensions in Bison.
Paul> If we're talking about the "%union foo {" change, I agree that it
Paul> would be much nicer if we could do this in the parser than do it in
Paul> the lexer. The main reasons I did it in the lexer were (1) I don't
Paul> know the syntax for C++ well, and some bug reports in this area were
Paul> C++-related so I'd like to support whatever C++ needs, and that
Paul> requires knowing the C++ grammar to do a parser-based change, and (2)
Paul> Bison used to do it in the lexer, so I was sure that the change would
Paul> fix the regression.
Hm, I thought I had already made clear that C++ wants the tag and the
type to be equal.
But the point is that anyway this feature is dubious. I am not
convinced at all it should make it (back) into Bison. And I don't
care what Solaris Yacc says about this. It collides with future
extensions, might cause problems with --prefix etc. This is just not
a good idea.
Paul> I would favor further cleanups by supporting this extension in the
Paul> parser rather than the lexer, but I'd like to know the answer to (1)
Paul> before proposing such a cleanup. I'd rather not simply reverse the
Paul> patch, since I don't want to break backward compatibility without a
Paul> compelling technical reason. And so far, I haven't seen a reason that
Paul> is compelling enough. Certainly I don't want to unduly hamper future
Paul> extensions, but I don't know what the extensions you are thinking of
Paul> in this area so I don't know what would hamper them and what would
Paul> not.
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. Actually, even the very syntax of
%union is a failure, and imho, Lemon had it right: there is no reason
for the user to know the name of the fields. But that's not
important.
In the present case I'm not inclined to include this feature because
even with an id, it will complicate the program for a no additional
feature: the very feature is provided by the language itself, so I see
no point in having it in addition on Bison.
- 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 <=
- Re: %union foo bar baz and others { ... }, Paul Eggert, 2003/01/20
- 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