[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: |
Wed, 19 Dec 2018 16:05:27 +0100 |
> On 19 Dec 2018, at 15:38, Frank Heckenbach <address@hidden> wrote:
>
> Hans Åberg wrote:
>
>>> By default, I keep recipients (list) and CCs (Akim) as is.
>>
>> With a reply to all, it would come out right.
>
> Depends on what you consider right. It's a mailing list. Those who
> write here are expected to read via the list (subscription or
> archive; I know you do) or take their own measures (Reply-To or CC).
> With "reply to all", I get all of your mails twice, doesn't seem
> right to me (though only slightly annoying these days, as opposed to
> 20 years ago when every KB of internet data cost a fortune ;).
That can be changed in you list subscription. The emails I get have both your
address and bug-bison, so you perhaps already get two copies anyway on the
reply-alls.
>>> If you
>>> want a private copy, set a Reply-To.
>>
>> Those are generally bad.
>
> I don't agree. Some years ago there was a somewhat famous rant
> against them, but it was full of BS and misunderstandings.
>
> Or you can set a CC to yourself if you wish.
I simply did not know why you had this funny cc'ing to some, but not to me.
Don't worry about it.
>> I might not notice your posts, so do as you wish.
>
> Honestly, you *not* noticing my posts is one of my smallest worries. ;)
Well, I apologize for replying to your email, but it seemed directed to be.
>>>>>> 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.
>>>
>>> I don't use flex anymore, and never used flex C++, so I don't know
>>> about that. But again, that's unrelated to the current proposal.
>>
>> It was in response to your comment.
>
> Which was in response to your comment about some mysterious "extra
> arguments".
I do not use %param, don't worry about the other.
>> There might be a problem with the Bison variant if one in the
>> lexer returns an object of another type that the token type, and
>> expect a conversion.
>
> There is no conversion, and in most cases, there couldn't be any
> when types are too different; but even if types are similar enough
> that a safe automatic conversion would be possible, say char to int,
> I know of no variant or union that would do so. That's not specific
> to Bison's variant.
>
> So such a mismatch is an error. The only difference is how this
> error is handled. std::variant throws an exception on usage; Bison's
> variant so far basically makes it UB (which is a valid answer; many
> things in C++ are UB), the current proposal would report an error on
> construction already, so slightly better than std::variant (in case
> the mismatching value is silently discarded).
Two lookup table variations: The values are stored, with the token value, as a
pointer to a base class, or as variants.
- Re: Dynamic token kinds, (continued)
- 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, 2018/12/17
- 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 <=
- 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
Re: Dynamic token kinds, Frank Heckenbach, 2018/12/21
Re: Dynamic token kinds, Akim Demaille, 2018/12/22
Re: Dynamic token kinds, Frank Heckenbach, 2018/12/22