Re: yytype_FOO (was: [PATCH 0/6] api.value.type support)

[Akim Demaille]

(Hi Paul, I'd be happy to have your opinion about this, time permitting).

Hi all,

I would really like to release in a not too distant future, but there
are issues on which I'd feel better if I had opinions.  There are two
questions below.

Le 25 févr. 2013 à 11:51, Akim Demaille <address@hidden> a écrit :
> Le 24 févr. 2013 à 18:15, Joel E. Denny <address@hidden> a écrit :
>> On Sat, 23 Feb 2013, Akim Demaille wrote:
>>> The value "union" means that the user provides genuine types, not
>>> union members names such as "ival" and "sval" above.
>>> 
>>>   %define api.value.type "union"
>>>   %token <int> INT "integer"
>>>   %token <char *> STR "string"
>>>  /* In yylex().  */
>>>   yylval.yytype_INT = 42; return INT;
>>>   yylval.yytype_STR = "42"; return STR;
>> 
>> What does the "yytype_" prefix mean?
> 
> Nothing particular.  I would prefer not using any prefix at all,
> and be able to write
> 
>       yylval.INT = 42; return INT;
> 
> but currently we still issue the %token definitions as follows:
> 
> $ cat /tmp/f.y
> %token PLUS MINUS NUMBER
> %%
> exp:
> $ ./_build/48d-debug/tests/bison -yd /tmp/f.y
> $ grep -P 'PLUS|MINUS|NUMBER' y.tab.h
>    PLUS = 258,
>    MINUS = 259,
>    NUMBER = 260
> #define PLUS 258
> #define MINUS 259
> #define NUMBER 260
> 
> So that would not work.  The #define are there only because of
> -y. I would be happy to forbid api.value.type=union
> if --yacc is passed, but then again Automake is a problem because it
> uses -y.

This problem can easily be addressed: please should redefine
YACC as 'bison -o y.tab.c' instead of 'bison -y'.  

> Alternatively, I could change the above definition into
> 
>    PLUS = 258,
>    MINUS = 259,
>    NUMBER = 260
> #define PLUS PLUS
> #define MINUS MINUS
> #define NUMBER NUMBER
> 
> that should work.  Of course I would also honor api.token.prefix here,
> e.g., with api.token.prefix=TOK_
> 
>       yylval.TOK_INT = 42; return TOK_INT;

My questions are:

- (mostly for Paul), do you think it is OK for Bison to #define
  the token symbols to their enum definition rather than their
  numerical value?  

  http://pubs.opengroup.org/onlinepubs/009695399/utilities/yacc.html
  reads:

    Header File
    The header file shall contain #define statements that associate
    the token numbers with the token names. This allows source files
    other than the code file to access the token codes.

  Pointing to the enums does point to the values in a way, and it
  does not in another.  I fail to see why one would like to depend
  on a token number during preprocessing, but that's the only
  difference I see.

- would someone object to naming the union members after the
  corresponding token name?  I.e.

  %token <int> INT
  
  results in the following line in the scanner:

  yylval.INT = 42; return INT;

  and

  %define api.token.prefix TOK_
  %token <int> INT
  
  results in:

  yylval.TOK_INT = 42; return TOK_INT;

  The other symbols (e.g. %type <INT> exp exp.0) would rather generate
  a member name that is prefixed with some string, for instance
  yytype_exp for the first one, and yytype_13 for the second, as its
  name is not an identifier.  These symbols are not exposed to the
  user, so it does not matter that their names are obfuscated.