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

[Akim Demaille]

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 <address@hidden> 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?