bug-bison
[Top][All Lists]
Advanced

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

Re: Dynamic token kinds


From: Frank Heckenbach
Subject: Re: Dynamic token kinds
Date: Sun, 16 Dec 2018 15:48:00 +0100

Hans Åberg wrote:

> > On 16 Dec 2018, at 11:13, Frank Heckenbach <address@hidden> wrote:
> > 
> > Hans Åberg wrote:
> > 
> >> Perhaps an entirely static approach can be achieved by the type
> >> being a part of the token_type. On the other hand, the use is for
> >> dynamic token lookup, so it may be too much of an effort for that.
> > 
> > Not sure what you mean with "part of", but with Bison's variant the
> > semantic type is determined by token_type, if that's what you mean.
> 
> The idea would be that rather than returning the token value,
> something that does not need translation. I don't know if that
> helps up the static approach, though.

Not sure what you mean here. Please elaborate.

> >> Personally, I am already at C++17, so I have no reason for using a
> >> simpler variant. Having the type stored just adds a size_t, and
> >> that is used a lot in other circumstances, so no overhead to worry
> >> about.
> > 
> > Well, we had this discussion recently (as far as Bison is
> > concerned).
> 
> Indeed, but that was where it seemed not requiring the type being
> stored in the variant. This situation might be different in that
> respect.
> 
> Here, not making sure the type is properly returned may bomb the
> program, so preventing that seems higher than a rather small
> overhead.

I think Akim made it clear enough that he doesn't like the overhead.
(I don't mind so much, as I used std::variant in my implementation,
but I only have a few parsers to care about.)

One might validly say that preventing it is the job of the lexer
(and my lexer does so), not Bison's, just like other kinds of
undefined or wrong behaviour outside of the generated code, also
dynamic token types are a somewhat special usage anyway, so Bison
can just do nothing about it, that's fine.

I also suggested an approach in my previous mail with a few more
generated functions that help runtime checking. I'd prefer Bison to
add them, and then we'd have runtime checking as good as we'd have
with std::variant in this respect.

Regards,
Frank



reply via email to

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