[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %union ... {
From: |
Akim Demaille |
Subject: |
Re: %union ... { |
Date: |
Fri, 16 Jun 2006 17:05:16 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
>>> "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; };
- Re: Dubious features, (continued)
- Re: Dubious features, Paul Eggert, 2006/06/07
- Re: Dubious features, Akim Demaille, 2006/06/08
- Re: Dubious features, Paul Eggert, 2006/06/08
- Re: Dubious features, Akim Demaille, 2006/06/08
- Re: Dubious features, Akim Demaille, 2006/06/08
- Re: Dubious features, Paul Eggert, 2006/06/08
- Re: Dubious features, Akim Demaille, 2006/06/08
- Re: Dubious features, Paul Eggert, 2006/06/08
- Re: Dubious features, Akim Demaille, 2006/06/10
- Re: Dubious features, Paul Eggert, 2006/06/11
- Re: %union ... {,
Akim Demaille <=
- Re: %union ... {, Paul Eggert, 2006/06/16
- Re: %union ... {, Akim Demaille, 2006/06/17
- Re: %union ... {, Paul Eggert, 2006/06/19
- Re: %union ... {, Hans Aberg, 2006/06/19
- Re: %union ... {, Akim Demaille, 2006/06/19
- Re: %union ... {, Paul Eggert, 2006/06/19
- Re: %union ... {, Akim Demaille, 2006/06/20
- Problems with CVS, Akim Demaille, 2006/06/20
- Re: Problems with CVS, Paul Eggert, 2006/06/20
- Re: %union ... {, Joel E. Denny, 2006/06/19