Re: Bison 1.30f

[Hans Aberg]

At 10:02 -0800 2001/12/20, Paul Eggert wrote:
>I am mostly talking about the constraints on the code generated by
>Bison.  One of those constraints is support for arbitrary C++ code, no
>matter how badly it is written.

I do not see why Bison should support badly written code, in C++ or any
other language. :-)

>I think you are mostly talking about something else: the API between
>other C++ code and the C++ code that Bison generates.  Here it is
>reasonable to design an API that avoids macros, if someone with C++
>expertise takes the time to write and maintain such an API.

I do not know what API's the C++ eventually should support -- I think that
will take some experimentation to figure out.

>But even if such an API is designed and maintained, the
>Bison-generated parser should still support arbitrary C++ code, even
>code that uses preprocessor macros in a deprecated style.

As Bison never has supported C++, there is no deprecated style to support.

>  It is
>sometimes useful for C++ programs to include C headers, even if those
>headers use poor C++ style; Bison should not preclude this.

If the Bison C++ puts its stuff in a C++ "namespace" construct, it cannot
clash with any C code.

Generally, I do not object if you want to have macros instead of C++
constructs in some compatibility mode. I do object however to the idea that
macros should be used to prohibit the better use of proper C++ constructs.

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