[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison C++ mid-rule value lost with variants
From: |
Akim Demaille |
Subject: |
Re: Bison C++ mid-rule value lost with variants |
Date: |
Sun, 12 Aug 2018 14:28:50 +0200 |
Hi Frank,
Sorry, I missed that message. I found it while exploring the
mid-rule action fiasco with variants.
> Le 19 juin 2018 à 00:27, Frank Heckenbach <address@hidden> a écrit :
>
> Akim Demaille wrote:
>
>> Well, you can use $<> wherever you want, in regular actions
>> too.
>
> And that's just as unsafe and hiding things from Bison. From the
> rest of your mail I now see you want to get rid of $<> completely in
> C++. I hadn’t gathered this from your previous mail.
Yes, indeed. $<> is really too low level a feature when
it is comes to ‘active types’ such as we have in C++ compared
to C. So we should not strive to have it work for dubious
cases (a type mismatch between the declared type and the one
passed to $<>), and allow to not use it (typed mid-rule actions).
> Though it does help when moving from C to C++ which I did recently
> (though my code was actually C++ the whole time, I had used the C
> skeleton before). If I had used $<>, and it was not available in the
> C++ skeleton, it would have been another hurdle at this point. In my
> case, I'm talking doubly hypothetically; for other users (as the
> original report indicates, there are people who use it) it may
> become relevant, but some kind of porting guide may help.
That’s a good idea. But I’m not sure what it should cover :)
>> We tried to eliminate these runtime problems and make them
>> compile-time as much as possible. A typical example
>> is the symbol constructors in C++, which forbid that in the
>> scanner you declare an INT and set yylval->float_val.
>
> Provided one uses them. Currently, this is not enforced (in fact,
> Piotr’s grammar didn't), so not strictly forbidden.
And I don’t want to forbid them. And since symbol constructors
appeared late, backward compatibility forbids that we require
them. Yep I think they are the proper way to do it, so I promote
them.
> FWIW, I wouldn't
> mind strictly forbidding it (maybe by making other constructors
> private and adding friends as necessary or whatever is required).
If it were to be designed today, I would do that.
>> I'm sorry if I gave the impression I would not provide support
>> for modern C++, that's definitely not my point. I want to
>> avoid _requiring_ it, but, if __cplusplus__ is modern enough,
>> we absolutely should support move semantics! I'm focus on this
>> issue now just because I'm trying to catch up! And it seems to
>> me that it shows we don't need to require std::variant.
>
> If you're willing to drop $<> completely in C++ (both in mid-rule
> and regular actions), it’s probably possible to avoid std::variant.
I’m willing to discourage the use of $<> in all the outputs,
but forbid them when there’s really no way to support them.
> When I did the coding, std::variant actually simplified things for
> me (e.g., I could avoid adding move support in Bison's variant
> implementation), so if I were you, I'd probably use it even if I
> dopped $<>, but if you want to avoid its small runtime overhead,
> that seems possible.
I don’t think we can afford to simply drop all C++s pre 17.
You did wonders with your C++17 skeleton, and it would be
great to port your effort in the current framework. Would
you contribute to that?
- Re: Bison C++ mid-rule value lost with variants,
Akim Demaille <=
- Re: Bison C++ mid-rule value lost with variants, Frank Heckenbach, 2018/08/26
- Re: Bison C++ mid-rule value lost with variants, Akim Demaille, 2018/08/27
- Re: Bison C++ mid-rule value lost with variants, Hans Åberg, 2018/08/27
- Re: Bison C++ mid-rule value lost with variants, Frank Heckenbach, 2018/08/28
- Bison lexer, Hans Åberg, 2018/08/29
- Re: Bison lexer, Frank Heckenbach, 2018/08/31
- Re: Bison lexer, Hans Åberg, 2018/08/31
- Re: Bison lexer, Frank Heckenbach, 2018/08/31
- Re: Bison lexer, Hans Åberg, 2018/08/31
- Re: Bison C++ mid-rule value lost with variants, Frank Heckenbach, 2018/08/28