> On 17 Dec 2018, at 19:09, Frank Heckenbach <[email protected]> wrote:
[Note: you don't cc me, only others, for some reason.] >>> On 17 Dec 2018, at 18:37, Frank Heckenbach <[email protected]> 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.
