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

[Hans Åberg]

> On 15 Apr 2020, at 17:45, Akim Demaille <address@hidden> wrote:
> 
>> 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".

If one is focusing on other parts, it is good not having fix the .yy file. :-)


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

Maybe call them grammar_token and parser_token, then.


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

They can be called terminals and nonterminals.


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

It seems these names refer to various internal numbers.


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

I think it is unkind! :-) The word “kind” does not seem to be in line with any 
C++ lingo at least.