Re: RFC: enum instead of #define for tokens

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> From: Akim Demaille <address@hidden> Date: 02 Apr 2002 16:34:35
>> +0200
>> 
>> Does POSIX mandate something?

Paul> POSIX 1003.1-2001 requires that the header file must contain
Paul> #define directives for each token code assigned by yacc.  The
Paul> symbols must be defined to be "numbers".  

OK, thanks!


Paul> This raises another issue, though.  Some pedantic compilers
Paul> complain about mixing enum and int.  So if you make the above
Paul> change, the pedantic compilers will make you want to go through
Paul> bison.simple and manually replace 'int' with 'enum yytokentype'
Paul> where that is needed.  

I was thinking about yyttype, for consistency with yystype, and
yyltype.

Paul> But that's not a good idea, as it would introduce compatibility
Paul> problems, since the enum type is not type-compatible with int,
Paul> so programs that contain declarations like `int yylex ();' will
Paul> break.

Indeed.

Paul> So, all in all I would do something like the following instead.
Paul> This is a more conservative change, and is less likely to break
Paul> things.

   #ifndef YYTOKENTYPE
   # if defined (__STDC__) || defined (__cplusplus)
      /* Put the tokens into the symbol table, so that GDB and other debuggers
         know about them.  */
      enum yytokentype {
        FOO = 256,
        BAR,
        ...
      };
      /* POSIX requires `int' for tokens in interfaces.  */
   #  define YYTOKENTYPE int
   # endif
   #endif
   #define FOO 256
   #define BAR 257
   ...

It does look good, but would some people really use it?  Now that I
know we are bound by POSIX to #define, I'm tempted to leave it as is
for C, and provide something better only for C++.  What is your opinion?



Paul> The __cplusplus is for backward compatibility with folks who
Paul> compile C programs using C++ compilers; there seem to be a good
Paul> number of these people so I wouldn't shut them off right away
Paul> even if we have a different and better way to do it now.

Yep.  Actually, I think I was wrong when I said that the trick you
implemented for 1.3x was not to be installed in 1.5x.  It should
probably be applied there too.