help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: yytname woes


From: James K. Lowden
Subject: Re: yytname woes
Date: Sun, 12 Nov 2023 18:13:55 -0500

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!)  

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

--jkl



reply via email to

[Prev in Thread] Current Thread [Next in Thread]