Re: Bison 1.30f

[Hans Aberg]

At 16:17 -0800 2001/12/19, Paul Eggert wrote:
>> The Yacc compatible program must be able to produce such names in some
>> mode, but not always in any mode.
>
>Yes, and the only modes that are required are the ones prescribed by
>the standard.  However, it makes sense (all other things being equal)
>to use the same solution for both standard modes and for extensions.

I think that under C, it is not a language well designed for exporting many
names to the linker: So if you think macro names helps for that, then I can
see you want them.

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

>  I assume C++
>is similar.

This is wrong: C++ is not similar to C relative the preprocessor, because
even though one can use the preprocessor for compatibility reasons, C++ has
language constructs intended to replace the preprocessor.

If you look at the C++ standard, you will find that almost all names that
were macros under C are now available under C++ as proper language names:
There are special standard headers available for such things. For example,
the C header <limits.h> is available under C++ as C compatibility headers
<limits.h> and <climits>, but there is now a C++ standard header called
<limits>, which defines these numbers in the form
  template <>
  class numeric_limits <char> {
  public:
    static const bool is_specialized = true;
    static char min() _MSL_THROW {return CHAR_MIN;}
    static char max() _MSL_THROW {return CHAR_MAX;}
    static const int  digits = 7;
    static const int  digits10 = 3;
    ...
  };
So it does not contain any macro names.

The headers <limits.h> and <climits> are "deprecated features, where
deprecated is defined as: Normative for the current edition of the
Standard, but not guaranteed to be part of the Standard in future
revisions."

This means that one is in the current standard guaranteed to be able to use
the old C standard macro names, but not in the future C++ standards: These
macro names may in fact be removed. This is a strong suggestion that one
should not use these macro names under C++ unless one absolutely must.

Some things cannot handled by that, for example macros like YYDEBUG that
selects code for the compiler. But I found the fact that YYDEBUG not
changing its YY by the --name-prefix option inconvenient when working with
more than one parser.

>> 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.
>
>That may be a goal, but it hasn't been achieved.

So for those components of C++ for which there are preprocessor
replacements, one is using them.

> Until the
>preprocessor language is removed from all active C++ compilers, Bison
>will need to assume that C++ programmers will (ab)use the preprocessor.
>It's not Bison's job to enforce programming style rules.

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++
programming. It is rather pointless to program C++ as it were a variation
of C, because then C is much better for that.

There is often no need for macro names and special initial name extensions
like yy and YY under C++, as one can always put it in a C++ "namespace
<name> {...}" construct. C++ is specifically designed so that one can
export many more names, without making them to clash.

  Hans Aberg