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