> On 15 Apr 2020, at 17:45, Akim Demaille <[email protected]> wrote: > >> Le 15 avr. 2020 à 10:56, Hans Åberg <[email protected]> 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.
