Re: yytname woes

[Christian Schoenebeck]

On Monday, November 13, 2023 12:13:55 AM CET James K. Lowden wrote:
> On Mon, 13 Nov 2023 20:15:44 +0100
> Christian Schoenebeck <schoenebeck@crudebyte.com> wrote:
> 
> > > 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. 
> 
> I appreciate that, Christian, really.  FWIW, I think it is your
> business, though.  The definition of a bug is behavior at variance with
> the documentation.  Bugs are errors.  They don't get fixed unless
> someone recognizes them.  
> 
> I would also suggest that if no one on help-bison@ can answer why a
> feature is "obsolescent" or what to do instead, then there's some gap
> between the text and the user community.  That's a problem.  
> 
> To your reply, 
> 
> > 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. 
> 
> I remember seeing that, yes. 
> 
> > 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)
> 
> I didn't try to understand that macro, or even the comment.  I like
> to use software according to its documented behavior and publc
> interface  YYTRANSLATE is not in the produced header file.  To use it
> would require, well, not using it.  I would have to reproduce it in my
> own code.  
> 
> That said, thank you for pointing it out.  If that's the best we've got
> -- reading the generated code and rooting around in its tables -- then
> that answers the basic question, more or less.  There is no documented
> public interface to convert an integer token to its name.  Strange, but
> true.  
> 
> Apart from bounds-checking, I think we're saying that token => name
> lookup can be accomplished with: 
> 
>       yytname[ yytranslate[token] ]
> 
> That's the answer I was looking for, and the one I think should be in
> the manual.  I'm still curious, though, why the manual includes the odd
> disclaimer, 
> 
>       This feature is obsolescent, avoid it in new projects.
> 
> I find it weird, really, that on a technical list such as this one, the
> simple yes/no question, "Is it a bug?" does not elicit a direct
> answer.  IIUC, you don't feel you're in a position to judge what the
> manual means, and so can't say if it's right or wrong.  (That's OK.
> Not everyone needs to have an opinon!)

That's not what I said, but as you are already asking for my opinion: overall 
I actually find the Bison user manual very well (not saying perfect), and I 
don't get where that high expectation comes from, that you simply drop a 
message on a user list and naturally expect people waiting to read your linked 
code and require them to first figure out what your actual intention was to 
access the forementioned deprecated API, and immediately respond to you with a 
convenient answer that just satisfies your needs.

/off-topic-end

The thing is yytname[] was always just meant to be used for providing custom 
syntax error messages (note: syntax error in the sense that it violates the 
grammar rules, not higher level semantic error/warning handling in action 
rules) and for that intended use case you do not need YYTRANSLATE(). Your use 
cases deviate from that intended one though.

Akim enumerated people's use cases of yytname[] he found in 2020, came up with 
an alternative (%define parse.error custom - which is also mentioned in the 
manual section of %token-table / yytname[] BTW), but also made it clear that 
this alternative would still just support the intended use case of custom 
syntax error messages:

https://lists.gnu.org/r/bison-patches/2020-01/msg00000.html

> Since it seems there's no public interface to what I consider to be
> useful functionality, I guess I'll file an issue.  

Sure, go ahead!

In general I think it does make sense to support use cases beyond the designed 
custom syntax error message one - simply because other use cases already 
exist.

But to answer your other question more directly: no, I don't think it's a bug, 
as you are using yytname[] for a purpose it was never designed for, and at the 
same time still showed you a way to accomplish what you intended it for, plus 
the fact that yytname[] is preceded with a comment that clearly tells that you 
were accessing it in a wrong way.

/Christian