(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 <[email protected]> a écrit : > Le 24 févr. 2013 à 18:15, Joel E. Denny <[email protected]> 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.
