Re: api.header.include and backward-compatible .y files

[Akim Demaille]

Hi Kaz,

> Le 5 sept. 2020 à 11:12, Kaz Kylheku <kaz@kylheku.com> a écrit :
> 
> On 2020-08-30 05:42, Akim Demaille wrote:
>> Let's face it: the POSIX spec for Yacc contains a lot of silly things.
>> For instance using #define for tokens is silly.  enums are the obvious
>> right choice.
> 
> I happen to have an #ifdef test for one of these tokens, which is a
> proxy for "y.tab.h has been included, and therefore YYSTYPE is declared".
> (I know about YYSTYPE_IS_DECLARED, but it is not portable!)

Just add whatever #define you need in the prologue (it will be part
of the generated header), and use it.  Or use --yacc.

You seem to be willing that Bison is tailored to your needs.  I think
it is flexible enough to address them.

> You can't just casually replace #define's with enum.

Of course I can't.  It must be a pondered decision, with several minds
if possible.  That was made years ago, when Bison had three maintainers.
So I don't see what your point is, but in Yacc mode Bison generates
#defines, and in Bison mode, it generates only enums, and has done so
for years.

* Noteworthy changes in release 2.3a (2006-09-13)

** Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with "-y",
  "--yacc", or "%yacc"), Bison no longer generates #define statements for
  associating token numbers with token names.  Removing the #define statements
  helps to sanitize the global namespace during preprocessing, but POSIX Yacc
  requires them.  Bison still generates an enum for token names in all cases.


There are tons of advantages with enums.  You get type safety, checked
coverage, debugging information, etc.

And I will not justify again something that is 16 years old.

> Imagine someone named some Yacc tokens TRUE and FALSE, and
> then the y.tab.h is pulled into code that defines these
> things.

api.token.prefix


>> The table "Internal Limits in yacc" is also a good
>> source of laugh.
> 
> Those are minimum limits.

Of course they are.  And they are ridiculously low.

> The numbers are likely based on historic values that were
> used in practice.

And they should be updated, or completely removed.

Cheers!