Re: Bison 1.30f

[Hans Aberg]

At 11:28 +0100 2001/12/21, Magnus Fromreide wrote:
>> Two possible ways mentioned in this list are to enhance the skeleton file
>> language, making it easier to write different skeleton files, and adding
>> support for writing out the info in XML, so that skeleton files can be
>> written using XML tools.
>
>When are you finished implementing any of the above mentioned schemes
>including having convinced the maintainers that any of them is good?

There has been a long time been a decision to make Bison to eventually
support C++, and further, quite recently, a decision has been made to make
Bison support C++ in some of the next few versions; I think Akim suggested
that perhaps 1.35 should have that.

I did not suggest the XML variation, but I think myself the worked up
skeleton file language more likely. At some point in time, it will then be
easy to write an XML file, so that would be automatic for those involved.

We have had some discussions in this group suggesting that this is the way
things will develop.

But it is always safer to wait and see.

>I am certain that they will agree to let you be maintainer of the C++
>style (or at least one of the possibly multiple ones) once you have that
>in place, at that point you could convert that ruleset to your hearts
>content _while_avoiding_to_clutter_the_C_style_.

I think that I mentioned in the last post that the genuine C++ paradigm
support will likely have its own skeleton file, for practical reasons, it
is simply easier not having to worry about C all the time. So it will have
nothing with C to do then.

As for developing the genuine C++ support, I think that will have to be
worked up over time, as there are many ways to go. Clearly, I am
experimenting with some of these C++ possibilities, and will provide my
input to this list.

>I will continue to state that YACC/Bison generates C code as output right
>now and thus rightly should ignore most C++ issues (If it can be written
>in the C subset that C++ implements without making it any harder from a C
>point of view then do that, bt do not implement things in a nonobvious way
>just to keep it this way!)

The development in we saw in Bison 1.30f is that is was fairly easy to
improve the "compile C as C++ support". Paul Eggert volunteered to put in
some of these changes, as they were relatively easy to do. As alloca
probably won't work in the C++ support, it might be suitable to keep this
mode.

But as you saw (I hope) from the other posts, that C++ compile can fail
miserably, with the new Bison stack re-allocation policy. If that can be
improved, why not do that as well.

But please note that this "compile C as C++" support does not have anything
to do with the other C++ support to come later.

  Hans Aberg