Re: Bison C++ mid-rule value lost with variants

[Frank Heckenbach]

Akim Demaille wrote:

> >> Piotr's grammar file includes:
> >> 
> >> %token <int> NUM
> >> %%
> >> expr:
> >>  NUM
> >> | expr { $<int>$ = 42; } '+' NUM { std::cout << $<int>2 << '\n'; };
> >> 
> >> and one can see that when run, $<int>2 is not 42, but 0.
> >> 
> >> My opinion on this is somewhat different from the ones that
> >> have been expressed so far.  IMHO, it has no good reason
> >> to work.
> >> 
> >> Yes, it works with plain old unions.  But that's unsafe, and
> >> that's because you hide things from your tool (Bison).
> > 
> > AFAIK, that's the only purpose of the $<> syntax in Bison which has
> > been around for I don't know how long. So claiming it has no reason
> > to work now seems a bit odd to me.
> 
> 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.

> And some people are doing nasty things with it in C,
> which forced, for backward compatibility with YACC, to keep
> weird code.
> 
> And as you know, YACC does not support C++, and obviously
> not (Bison) variants.  So to expect a « feature » from C to
> naturally work for C++ is not so straightforward.

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.

> 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. FWIW, I wouldn't
mind strictly forbidding it (maybe by making other constructors
private and adding friends as necessary or whatever is required).

> > What's more important for me, and the reason I worked on this, are
> > other features, most importantly move semantics. Of course, they
> > also require modern C++ (i.e., C++11 or newer), so if that's a
> > problem, I'll have to keep my own fork anyway.
> 
> 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.

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.

Regards,
Frank