Hi Akim, On Tue, 19 Mar 2013, Akim Demaille wrote:
> Ping! Sorry for my slow response. > Le 4 mars 2013 à 08:51, Akim Demaille <[email protected]> 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.
