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