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

[Joel E. Denny]

Hi Akim,

On Tue, 19 Mar 2013, Akim Demaille wrote:

> Ping!

Sorry for my slow response.

> Le 4 mars 2013 à 08:51, Akim Demaille <address@hidden> a écrit :
> 
> > - 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.

All this seems fine to me.  How did you decide to address the yacc #define 
issue?  I suppose it's OK to break with perfect yacc compatibility when 
using a non-yacc feature.