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

[Hans Åberg]

> On 15 Apr 2020, at 06:54, Akim Demaille <address@hidden> wrote:
> 
> Hi Hans,

Hello,

>> Le 14 avr. 2020 à 22:27, Hans Åberg <address@hidden> a écrit :
>> 
>> 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.

That does not look good, in my opinion. And you will break backwards 
compatibility, unless you add a ‘using' or a ‘typedef’ declaration.

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

In a formal definition, they are both symbols of the language, cf. Waite & 
Goos, “Compiler Construction”, p. 102. If one defines a grammar, the symbol 
constants are alos called tokens, the other are symbol variables. 

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

I am not sure exactly what you want to achieve. Would scoped enumerations [1] 
do? —They encapsulate the values in class.

1. https://en.cppreference.com/w/cpp/language/enum

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

Maybe symbol_value, then.

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

Maybe so. I only need the symbol value for the return to the parser from the 
lexer, and mostly, they are symbol constants (tokens), but I am not sure they 
always have to be.