bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/5] c++: improvements on symbol kinds


From: Akim Demaille
Subject: Re: [PATCH 3/5] c++: improvements on symbol kinds
Date: Wed, 15 Apr 2020 06:54:05 +0200

Hi Hans,

> Le 14 avr. 2020 à 22:27, Hans Åberg <address@hidden> a écrit :
> 
> 
>> On 11 Apr 2020, at 08:47, Akim Demaille <address@hidden> wrote:
>> 
>> Instead of
>> 
>>   /// (Internal) symbol kind.
>>   enum symbol_kind_type
>>   {
>>     YYNTOKENS = 5, ///< Number of tokens.
> ...
>> generate
>> 
>>   /// Symbol kinds.
>>   struct symbol_kind
>>   {
>>     enum symbol_kind_type
>>     {
>>       YYNTOKENS = 5, ///< Number of tokens.
> ...
> 
> I use symbol table lookups of the form:
>  std::optional<std::pair<my::the_parser::token_type, my::value>> x = 
> mli::symbol_table.find(yylval.text);
> 
> What will the new name be?

I don't plan to break compatibility here.  I'm providing better names.
In your case, instead of token_type it should be token_kind_type.

> The most logical from the user point of view would be to have 
> the_parser::symbol_type.

"symbol" is incorrect, because here we are referring to a token as returned by 
the scanner. "type" is incorrect because it refers to the typing in C++ rather 
than the nature of this token.

So actually it would be "token_kind_type".

And anyway, symbol_type is already used to denote the type (C++) of symbols (a 
triple: kind, value, location).

In retrospect, it would have been better to have it named "token_type", and 
"stack_symbol_type" would have been "symbol_type".


reply via email to

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