Hi Joel! Thanks a lot for your answer!
(Hi Stefano, again, some rants against -y :) Le 24 févr. 2013 à 18:15, Joel E. Denny <[email protected]> a écrit : > Hi Akim, > > On Sat, 23 Feb 2013, Akim Demaille wrote: > >> This new %define variable supersedes the #define macro YYSTYPE. The use >> of YYSTYPE is discouraged. In particular, #defining YYTSYPE *and* using >> %union or %defining api.value.type > > The precedence of "and" vs. "or" is confusing here. Replacing "and" with > "and either" would clarify it, I think. Thanks for the tip! >> results in undefined behavior. > > Instead of leaving it as undefined behavior, could there be a #error? Yes, you are right, that would be much better. Will do. >> The %define variable api.value.type supports several special values, >> examplified below: > > s/examplified/exemplified/ Thanks! I should have run ispell first :( >> 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" > > Nice. Yep. I hope people will like it. >> /* 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. 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; Automake's use of -y is really troublesome. Actually, it is rather Autoconf which is a PITA here, that's it that decides to define 'YACC=bison -y'. Also, currently we have a (hidden) option which is a synonym of --yacc: { "fixed-output-files", no_argument, 0, 'y' }, { "yacc", no_argument, 0, 'y' }, It should rather just change the output file names to be y.tab.c and so forth, but not set -Wyacc. And Autoconf should use it. Meanwhile there is one way out: have people pass -Wno-yacc to their flags. >> The value "variant" is somewhat equivalent, but for C++ special provision >> is made to allow classes to be used. >> >> %define api.value.type "variant" >> %token <int> INT "integer" >> %token <std::string> STR "string" >> >> Any other name is a user type to use. This is where YYSTYPE used to >> be used. > > This seems troublesome to me for two reasons. First, it means a user > typedef name "variant" cannot be used, and that's a strange restriction. Yes, I know, it bugs me too. > (Fortunately, "union" and "%union" are not in the user namespace.) Exactly. At some point I meant to have only "union", and use the "variant" implementation when in C++ skeletons. But the user interfaces are really different then at the yylex level. (but anyway lalr1.cc _is_ a different API, so this argument is very weak). I'm am still not sure it was the best choice, maybe I should really replace "variant" by simply "union" in lalr1.cc. Any opinion? > Second, it means there's no clean way to extend Bison's special values for > api.value.type in the future. Could we have some notation to move special > values into a separate namespace from user type names? One of the > following, maybe: > > %define api.value.type "type: foo" > %define api.value.type "{foo}" > %define api.value.type {foo} In your examples "foo" is one of the special types, right? That would be a new notation in Bison, how about something like this: %define api.value.type "" %define api.value.type "int" %define api.value.type "%union-directive" // was %union %define api.value.type "%union" // was union %define api.value.type "%variant" The %union-directive case should never be spelled out, that's implied by using %union. Actually it should be an error to define api.value.type and using %union. What do you think about this?
