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

[Akim Demaille]

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

I'll let you guess what I mean when I say "I don't plan to break compatibility 
here".  I venture you're aware I know about "typedef" and "using".

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

We have more than a grammar here, we have a parser.  So "token" means two 
things: token-in-the-grammar, which only is a kind, and token-in-the-parser, 
that has a kind, a value, and a location.

I personally do not like the name "variable" for nonterminals.  It does not 
convey the right semantics imho.


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

Let's just focus on one topic at the time, and just jumping to other vaguely 
relation topics.



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

No, that would refer to... the symbol's value.


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

So that's the kind.