bison-patches
[Top][All Lists]
Advanced

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]