Re: Porting to typed C++ parser (was: Dynamic token kinds)

[Hans Åberg]

> On 17 Dec 2018, at 19:09, Frank Heckenbach <address@hidden> wrote:

[Note: you don't cc me, only others, for some reason.]

>>> On 17 Dec 2018, at 18:37, Frank Heckenbach <address@hidden> wrote:
>>> 
>>> Do you actually use Bison's variant? Otherwise, what you do is
>>> irrelevant here (sorry), as this is a proposal specifically about
>>> Bison's variant.
>> 
>> As I said, I do not use it now, but I wanted to know whether I
>> could use it before actually attempting to convert to it, which
>> may be irrelevant in your programming approach. I have used a
>> typed C++ parser I wrote myself before Akim started to write one,
>> but then it wasn't very useful.
> 
> OK, that's a different question (I think the issue about adding
> type-checks is settled now, just waiting for Akim's confirmation);

Specifically, I only have use for it simplifying casts and type checks, not as 
optimization.

> so:
> 
>> Actually, I pass the semantic value through a class object to
>> which the lexer function belongs, so the extra arguments are not
>> needed. So I must think more about this.
> 
> FWIW, my lexer function is also part of a "driver" object, but I
> don't think that's relevant here. Maybe you think of the "%param"
> arguments, but it's not about those.

No, I use the Flex C++ parser right now, which for some reason requires an 
empty argument, so this works without patching the header, that is, until they 
decided to bomb it in 2.6 and later.

> In my proposal:
> 
>  symbol_type make_symbol (token_type type, int &&);
> 
> the second parameter is actually the semantic value (and the first
> one the token kind, of course), so there are no extra arguments, no
> driver, no lexer, not even the parser (no hidden "this" parameter,
> since these are static functions), so I think there's nothing to
> worry about. It's just about building a token from these two
> parameters, as you'd expect to, by basically calling its
> constructor, and (as per the proposal) adding checks to help avoid
> mismatches between the two of them.
> 
> But if you tell us more about how you (plan to) build your tokens,
> we could say if there are any potential problems.

I use a polymorphic (virtual) pointer class, a string, a token number, or a 
combination thereof depending on context. For the first, it might be useful 
with typecasts that simplify the code.