bug-bison
[Top][All Lists]
Advanced

[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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]