Re: Bison 1.30f

[Hans Aberg]

At 11:36 +0100 2001/12/13, Akim Demaille wrote:
>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.

Th epoint of making the C++ namespace change is that it looked quite simple
to do.

Also, as alloca seems to drop out of the genuine C++ support, perhaps one
should keep the current bicon.simple for a combined C/C++ support.

>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.

The problem is clearly less, because of this; but it will affect the C++
code in the .y files.

>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.).

I view this as just a small thing that could be put in if the effort isnät
too big.

The issues will re-emerge when genuine C++ support is added in a later
version, so the discussions now is a kind of preparation for that.

>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.

As said above, because of the alloca/C++ problem, one may decide to keep both.

  Hans Aberg
                  * Email: Hans Aberg <mailto:address@hidden>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>