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

2018-11-28 Thread Akim Demaille
> Le 17 juin 2018 à 16:33, Rici Lake a écrit : > > Although unrelated to this proposal, I would also favour allowing > > %% > nonterminal: rhs > > as an alternative to > > %type nonterminal > %% > nonterminal: rhs FTR, the more I contemplate this idea, the more I like it. Unfortunately

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

2018-08-28 Thread Frank Heckenbach
Akim Demaille wrote: > > IMHO, "active types" aren't really the problem (as std::variant or > > an equivalent implementation can handle them), but indeed it's too > > low-level and error-prone, though that would apply to all skeletons > > (but of course, dropping it from C is impossible because

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

2018-08-28 Thread Frank Heckenbach
Hans Åberg wrote: > > On 27 Aug 2018, at 22:10, Akim Demaille wrote: > > > >> Most of my porting work, apart from writing the new skeletons, was > >> general grammar cleanup and conversion of semantic types from raw > >> pointers and containers to smart pointers and other RAII classes > >>

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

2018-08-27 Thread Hans Åberg
> On 27 Aug 2018, at 22:10, Akim Demaille wrote: > >> Most of my porting work, apart from writing the new skeletons, was >> general grammar cleanup and conversion of semantic types from raw >> pointers and containers to smart pointers and other RAII classes >> (which was my main goal of the

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

2018-08-27 Thread Akim Demaille
Hi Frank! Thanks for the feedback about 3.1! > Le 27 août 2018 à 00:39, Frank Heckenbach a écrit : > > Akim Demaille wrote: > >>> Le 19 juin 2018 à 00:27, Frank Heckenbach a écrit >>> : >> >> Yes, indeed. $<> is really too low level a feature when >> it is comes to 'active types' such as

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

2018-08-26 Thread Frank Heckenbach
Akim Demaille wrote: > > Le 19 juin 2018 à 00:27, Frank Heckenbach 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

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

2018-08-12 Thread Akim Demaille
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 a écrit : > > Akim Demaille wrote: > >> Well, you can use $<> wherever you want, in regular actions >> too. > > And that's just as unsafe

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

2018-06-18 Thread Frank Heckenbach
Akim Demaille wrote: > >> Piotr's grammar file includes: > >> > >> %token NUM > >> %% > >> expr: > >> NUM > >> | expr { $$ = 42; } '+' NUM { std::cout << $2 << '\n'; }; > >> > >> and one can see that when run, $2 is not 42, but 0. > >> > >> My opinion on this is somewhat different from the

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

2018-06-18 Thread Akim Demaille
> Le 18 juin 2018 à 15:26, Frank Heckenbach a écrit : > > Akim Demaille wrote: Hi Frank, >> Piotr's grammar file includes: >> >> %token NUM >> %% >> expr: >> NUM >> | expr { $$ = 42; } '+' NUM { std::cout << $2 << '\n'; }; >> >> and one can see that when run, $2 is not 42, but 0. >> >>

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

2018-06-18 Thread Frank Heckenbach
Akim Demaille wrote: > Piotr's grammar file includes: > > %token NUM > %% > expr: > NUM > | expr { $$ = 42; } '+' NUM { std::cout << $2 << '\n'; }; > > and one can see that when run, $2 is not 42, but 0. > > My opinion on this is somewhat different from the ones that > have been expressed

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

2018-06-17 Thread Hans Åberg
> On 17 Jun 2018, at 16:02, Akim Demaille wrote: > Or go for a lighter syntax... Indeed. > expr: > NUM > | expr { $$ = 42; } '+' NUM { std::cout << $2 << '\n'; }; > Personally, I prefer the prefix forms, but they don’t blend > nicely with named references: > > expr: > NUM > | expr { $$ =

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

2018-06-17 Thread Rici Lake
I enthusiastically support this proposal. I agree with the preference for prefix positioning. The `%type` keyword is just noise, imho, and thus unnecessary. I like the `name={ code }` syntax, too, but it's probably too late for that. Perhaps `{ code }[name]` would be a plausible alternative

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

2018-06-17 Thread Akim Demaille
Hi all, > Le 29 juin 2017 à 15:55, Piotr Marcińczyk a écrit : > > I supposedly found a bug in lalr1.cc skeleton with variant semantic type. > When using mid-rule action { $$ = value; } to return a value that > will be used in further semantic actions, it appears that the value on > stack

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

2018-04-08 Thread Frank Heckenbach
Hans Åberg wrote: > > On 29 Jun 2017, at 15:55, Piotr Marcinczyk wrote: > > > > I supposedly found a bug in lalr1.cc skeleton with variant semantic type. > > You might check if std::variant, of C++17, can be used instead. Cf. >

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

2017-06-29 Thread Hans Åberg
> On 29 Jun 2017, at 15:55, Piotr Marcińczyk wrote: > > I supposedly found a bug in lalr1.cc skeleton with variant semantic type. You might check if std::variant, of C++17, can be used instead. Cf. http://en.cppreference.com/w/cpp/utility/variant > When using mid-rule

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

2017-06-29 Thread Piotr Marcińczyk
Thanks for the workaround. Actually, I used marker tokens with actions getting value from stack before the rule, e.g.: %type AnswerToLifeMarker expr: expr AnswerToLifeMarker + NUM { std::cout << $2 << std::endl; }; AnswerToLifeMarker: { usePreviousExpr($0); $$ = 42; }; ​That's because I need

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

2017-06-29 Thread Kaz Kylheku
On 29.06.2017 06:55, Piotr Marcińczyk wrote: I supposedly found a bug in lalr1.cc skeleton with variant semantic type. When using mid-rule action { $$ = value; } to return a value that will be used in further semantic actions, it appears that the value on stack becomes zero. Tested with Bison