Re: yytname woes

[Christian Schoenebeck]

On Sunday, November 12, 2023 6:18:30 PM CET James K. Lowden wrote:
> On Mon, 13 Nov 2023 12:33:57 +0100
> Christian Schoenebeck <schoenebeck@crudebyte.com> wrote:
> 
> > > When I look up #899, NOT, I get "NOT".  But when I look up #900,
> > > NE, I get "'<'" because that's the next element in yytname (900 -
> > > 255).
> > [...]
> > 
> > Are you aware that yytname[] is indexed by "symbol-number", not by
> > "token- number", as it contains terminals and non-terminals?
> 
> That's interesting.  No, I'm not.  Respectfully, how could I be?  
> 
> The term "symbol-number" does not appear in the Bison info manual.  The
> %token-table directive says
> 
>       "?yytname[I]? is the name of the token whose internal
>        Bison token code is I.' 
> 
> You tell me: what is a "Bison token code"?

Look, I am not judging how well Bison is documented or what good/bad
terminology Bison authors chose. It's not my business. You asked a question
and I just read the auto generated parser code, which says:

  /* YYTNAME[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM.
     First, the terminals, then, starting at YYNTOKENS, nonterminals.  */
  static const char *const yytname[] =
  {
    ...
  }

Looking further down in the auto generated parser code I see:

  /* YYTRANSLATE(TOKEN-NUM) -- Symbol number corresponding to TOKEN-NUM
     as returned by yylex, with out-of-bounds checking.  */
  #define YYTRANSLATE(YYX)                                                \
    ((unsigned) (YYX) <= YYMAXUTOK ? yytranslate[YYX] : YYUNDEFTOK)

  /* YYTRANSLATE[TOKEN-NUM] -- Symbol number corresponding to TOKEN-NUM
     as returned by yylex.  */
  static const yytype_uint8 yytranslate[] =
  {
   ...
  }

And from the values in yytranslate[] it seems this is just the missing brick
you were searching for to accomplish your to task. Right?

As a side note: there is probably no other person on this list helping out
people with questions as often as Hans Åberg does. #tone

/Christian