[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Porting to typed C++ parser (was: Dynamic token kinds)
From: |
Hans Åberg |
Subject: |
Re: Porting to typed C++ parser (was: Dynamic token kinds) |
Date: |
Mon, 17 Dec 2018 21:17:49 +0100 |
> 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.
- Re: Dynamic token kinds, (continued)
- Re: Dynamic token kinds, Hans Åberg, 2018/12/16
- Re: Dynamic token kinds, Frank Heckenbach, 2018/12/16
- Re: Dynamic token kinds, Hans Åberg, 2018/12/16
- Re: Dynamic token kinds, Frank Heckenbach, 2018/12/17
- Re: Dynamic token kinds, Hans Åberg, 2018/12/17
- Re: Dynamic token kinds, Frank Heckenbach, 2018/12/17
- Re: Dynamic token kinds, Hans Åberg, 2018/12/17
- Re: Dynamic token kinds, Frank Heckenbach, 2018/12/17
- Re: Dynamic token kinds, Hans Åberg, 2018/12/17
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Frank Heckenbach, 2018/12/17
- Re: Porting to typed C++ parser (was: Dynamic token kinds),
Hans Åberg <=
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Frank Heckenbach, 2018/12/18
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Hans Åberg, 2018/12/18
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Frank Heckenbach, 2018/12/19
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Hans Åberg, 2018/12/19
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Frank Heckenbach, 2018/12/22
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Hans Åberg, 2018/12/22
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Frank Heckenbach, 2018/12/22
- Re: Porting to typed C++ parser (was: Dynamic token kinds), Hans Åberg, 2018/12/22
Re: Dynamic token kinds, Akim Demaille, 2018/12/19