bug-bison
[Top][All Lists]
Advanced

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

Re: Bison 1.30f


From: Hans Aberg
Subject: Re: Bison 1.30f
Date: Wed, 19 Dec 2001 12:10:36 +0100

At 18:00 -0800 2001/12/18, Paul Eggert wrote:
>I think we're going around in circles here, but to repeat the argument:

Let's make another 360, then. :-)

>A conforming program (in the .y file) can use whatever names it likes,
>  other than names beginning with yy or YY.
>Yacc must support such programs.
>To support those programs, yacc-generated names must be distinct from
>  user names.
>Hence yacc must generate only names starting with yy or YY.

The Yacc compatible program must be able to produce such names in some
mode, but not always in any mode.

>> or that names be visible to the preprocessor;
>
>But all the names we're talking about are visible to the preprocessor.

The question is whether POSIX requires the names to be visible to the
preprocessor. Do you have a quote that says that the names must be visible
to the preprocessor?

>> to me, it says that other programs
>> should not use them as the Yacc program may use them.
>
>That's another way of saying the same thing.

Nope. If one is sure to not use them, then one is sure to be able to
combine that with a Yacc generated parser, as it can be set to only produce
such names.

Besides, I think that POSIX is outdated relative Bison, as one always can
use a favorite prefix: Choose yy if one likes to, and that suffices.

In addition, I have several times used more than one parse in the same
program, and POSIX does not says how to handle such a situation.

>> Also, C++ isn't (I take it) part of POSIX, so whatever POSIX says
>> about macros under C, it is not valid under C++.
>
>True, but C++ is similar to C, and has similar problems with
>preprocessor names.  All other things being equal, it's simpler for
>both users and maintainers if we treat the languages similarly.

Nope: one of the main development goals of C++ is to replace uses that in C
are handled by macros (and thus are not part of the C language itself) with
C++ language constructs. This makes it easier for compilers to handle it
efficiently.

Therefore, unless there is a construct that cannot be handled by the C++
language itself, one should not use the preprocessor. (The stuff you are
saying could be interpreted as though are saying that the things that make
C++ an advantage over C should not be used.)

  Hans Aberg





reply via email to

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