[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: dogfooding: use api.value.type union
From: |
Akim Demaille |
Subject: |
Re: RFC: dogfooding: use api.value.type union |
Date: |
Sun, 11 Nov 2018 08:14:15 +0100 |
Hi Paul,
> Le 10 nov. 2018 à 18:16, Paul Eggert <address@hidden> a écrit :
>
> Akim Demaille wrote:
>
>> On the scanner side it is not too ugly to replace
>> val->uniqstr = uniqstr_new (last_string);
>> return TAG;
>> val->code = last_string;
>> return PROLOGUE;
>> with
>> val->TAG = uniqstr_new (last_string);
>> return TAG;
>> val->PROLOGUE = last_string;
>> return PROLOGUE;
>
> This is fine but I suggest not uppercasing the names, as the uppercase shouts
> "I AM A CONSTANT" and the identifier is no longer necessarily a constant.
I’m not sure I understand what you mean here. The tokens are no longer defined
as macros, granted, but they are still constants.
If you mean to change our token names into lower case, then you are actually
indirectly suggesting to depart from a long tradition.
Having taught formal language theory for years, I’m used to the universal
convention of using upper case for non terminal symbols and lower case for
terminal symbols. Having used Yacc, with its profound C roots, I’m also used
to the converse convention when writing parsers. Both conventions are logical
in their worlds.
Here, you are suggesting to use the same convention for both types of symbols?
I’m ok with that move, but wouldn’t that cause some confusion for some users,
especially beginners?
>> I also like to move from
>> {int} {
>> val->INT = scan_integer (yytext, 10, *loc);
>> return INT;
>> }
>> to
>> {int} RETURN_VALUE (INT, scan_integer (yytext, 10, *loc));
>> with the right macro RETURN_VALUE.
>
> Can we do that sort of thing without macros? Macros are trouble.
I dislike them too.
> Yes, we’re using macros already, but in this particular case it might be
> better to avoid them even if it's wordier.
What I like about them here is mostly that they allow to tend to the form I’d
like to have eventually:
{int} return make_INT (scan_integer (yytext, 10, *loc), loc);
And in this case, they allow to issue a single line in the scanner, rather than
four.