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

[Frank Heckenbach]

Hans Åberg wrote:

> > 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);
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. 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.

Regards,
Frank