[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: yytype_FOO (was: [PATCH 0/6] api.value.type support)
From: |
Akim Demaille |
Subject: |
Re: yytype_FOO (was: [PATCH 0/6] api.value.type support) |
Date: |
Mon, 4 Mar 2013 08:51:20 +0100 |
(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 <address@hidden> a écrit :
> Le 24 févr. 2013 à 18:15, Joel E. Denny <address@hidden> 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.
- Re: yytype_FOO (was: [PATCH 0/6] api.value.type support),
Akim Demaille <=