Re: RFC: renaming the symbol "types" as "kinds"

[Akim Demaille]

Hi Paul!

Thanks for the feedback!

> Le 4 avr. 2020 à 19:45, Paul Eggert <address@hidden> a écrit :
> 
> On 4/4/20 5:48 AM, Akim Demaille wrote:
>>      The yylex() function is an integer-valued function that
>>      returns a token number representing the kind of token read.
> 
> That phrasing would suggest "yytoken_number_t", no?

I don't want to emphasize the nature of tokens and symbols as numbers.
And they're not consistent, and use interchangeably about codes or numbers
(on this regard, I prefer "code", I don't see the need for arithmetics
as in "number".  Well, it is super important that we do have arithmetics
in the implementation of yyparse, but that's irrelevant for the user).
Besides, one refers to the code of '+', not its number.

That's POSIX, they don't even have an enum, they still refer to #define!
So they have no choice when they document the interface with yylex but to
refer to numbers.

Most of the page refers to "token names" though:

        The header file shall contain #define statements that
        associate the token numbers with the token names.
        This allows source files other than the code file to
        access the token codes.



        The following declares name to be a token:

        %token [<tag>] name [number] [name [number]]
        ...

        If tag is present, the C type for all tokens on this line
        shall be declared to be the type referenced by tag. If a
        positive integer, number, follows a name, that value shall
        be assigned to the token.


So I agree it somewhat suggests "yytoken_number_t" (I actually toyed with
it too), but I think it does not convey the right abstraction.

> Although "yytoken_kind_t" is also good, and a bit shorter.
> 
> You suggested "yysymbol_kind_t", but it might be better to distinguish 
> symbols from tokens here.

Maybe there's some confusion here. We need *two* types: one for
the tokens as returned by yylex, and another for symbols as processed
by yyparse (which does include the tokens, but with a different code).
I'm suggesting simultaneously yytoken_kind_t and yysymbol_kind_t:

>   enum yytoken_kind_t
>   {
>     GRAM_EOF = 0,     // (0)
>     STRING = 258,     // (1)
>     TSTRING = 259,    // (2)
>     PERCENT_TOKEN = 260, // (3)
>     [...]
>     PERCENT_UNION = 314, // (4)
>     PERCENT_EMPTY = 315  // (5), the last token
>   };

and

> enum yysymbol_kind_t
> {
>   YYSYMBOL_YYEMPTY = -2,
>   YYSYMBOL_YYEOF = 0,    // (0)
>   YYSYMBOL_YYERROR = 1,
>   YYSYMBOL_YYUNDEF = 2,
>   YYSYMBOL_STRING = 3,   // (1)
>   YYSYMBOL_TSTRING = 4,  // (2)
>   YYSYMBOL_PERCENT_TOKEN = 5, // (3)
>   [...]
>   YYSYMBOL_PERCENT_UNION = 59, // (4)
>   YYSYMBOL_PERCENT_EMPTY = 60, // (5)
>   YYSYMBOL_YYACCEPT = 61,      // $accept, the first nonterminal
>   YYSYMBOL_input = 62,
>   YYSYMBOL_prologue_declarations = 63,
>   YYSYMBOL_prologue_declaration = 64,
>   [...]
>   YYSYMBOL_string_as_id = 101,
>   YYSYMBOL_102_epilogue_opt = 102
> };

Cheers!