Re: Bison 1.30f

[Paul Eggert]

> Date: Thu, 20 Dec 2001 12:38:23 +0100
> From: Hans Aberg <address@hidden>

> >POSIX says that yacc must output "C source code, conforming to the ISO
> >C standard".  Almost all names in C source code are visible to the
> >preprocessor.  There are a few exceptions (comments, strings, and a
> >few positions in "#" lines) but they do not apply here.
> 
> But unless POSIX explicitly states that "there should be preprocessor macro
> names", it is a matter of style.

Yes, it is a matter of style.  Some C programmers like macros; others
don't.  Bison must support both kinds of programmers.  Hence the code
that it generates must work, even for programmers who like macros and
define ones with arbitrary names.  The only limitation on the macros
is that they cannot begin with yy or YY.

> C++ has language constructs intended to replace the preprocessor.

Some C++ programmers still use the preprocessor.  Bison should support
them.  Once the preprocessor is banished from C++, and all active C++
compilers lack preprocessor macros, then Bison can stop supporting
them for C++.  This won't happen for many years, though.

> But if you impose the use of preprocessor macros when better C++ language
> constructs are available, that also imposes a C programming style on C++

That is a separate issue.

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

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.  It is
sometimes useful for C++ programs to include C headers, even if those
headers use poor C++ style; Bison should not preclude this.