[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bison 1.30f

From: Akim Demaille
Subject: Re: Bison 1.30f
Date: 13 Dec 2001 11:36:54 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

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

>> From: Akim Demaille <address@hidden> Date: 12 Dec 2001 16:29:33
>> +0100
>> If you can reach an agreement, then please, Paul, install your
>> patch on both branches.  But I failed to see any such need
>> personally.  I do use Bison output with a C++ compiler, G++, and it
>> does work fine.

Paul> Yes, the current output works fine if your .y file doesn't use
Paul> any of the symbols reserved by bison.simple.  But haberg's point
Paul> is that (with C++) you shouldn't need to reserve _any_ symbols,
Paul> except for yy* and YY* symbols.

Paul> I think he's a bit off, as I think the code still must reserve a
Paul> few standard macro symbols like EOF and NULL in some non-default
Paul> cases.  But the rest of his point is a valid one.

Paul> Even if we assume GCC, the current skeleton does reserve some
Paul> non-macro identifiers that it needn't reserve, if a C++ user
Paul> defines YYDEBUG.  So this is not an issue that is limited to
Paul> non-GCC compilers.

Agreed, doubly agreed.  My point is that we can't please everybody,
and the worst of all would be to have a bigger and bigger
bison.simple, with lots of stuff for C++.  The point of bison.simple
is C period.  It turns out it works quite well with C++, but indeed,
enters the user name space.

But then, bison is meant to produce compilation units, not headers.
So I fail to see why it is so important not to import the standard
symbols.  Had bison produced such a .h, I would completely agree.
Currently, I tend to think we are fighting for something which is not
as relevant as the other problems (stupid calling convention (for the
caller of ypparse and for yylex), stupid constant names, yyerror which
lacks access to many of the relevant bits etc. etc.).

All these issues are issues I would have liked to deal with once Bison
is equipped with more logistics for different outputs.

>> I am not happy to see more weird stuff in bison.simple than there
>> was already before.

Paul> "bison.simple" is a relative term, isn't it?  (:-)

:)  Actually it has _never_ been.  Hairy does not deserve its name.
For the beginning I have the feeling that rms was a bit unfair when
naming his hairy skeleton bison.simple, and the simple skeleton
bison.hairy :)

>> After all, you can have another skeleton with you own C++ stuff.

Paul> So far the differences between the two languages are small
Paul> enough that I think it's easier to maintain one skeleton with a
Paul> few ifdefs, than to maintain two separate skeletons.

Y/N.  I am talking about _real_ C++ output, i.e., a Parser class.  You
are referring to making C parsers compile with strict C++ rules.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]