If I correctly understand, I meant both non terminal and terminal symbols. Because it will be usefull to attach attributes to tokens too.
So, there are plans to rewrite GLR to C++. What expect to done first: variants or refactoring? сб, 11 янв. 2020 г., 13:38 Akim Demaille <[email protected]>: > Hi, > > > Le 11 janv. 2020 à 10:38, Ookami <[email protected]> a écrit : > > > > Hello! Five years ago was a feature request about C++ variants for GLR. > The Bison documentation says that C++ Variants are not supported in GLR, > and C++17 variants will not be supported to maintain backward compatibility > with older versions of C++ standards. > > > > I know, that Valentin implementing C++ GLR variants. Is there any > progress? > > Yes, there are. However Valentin had to stop for a while, and > he will certainly come back to this in the near future. I don't > know exactly his plans though. > > > I wish to implement at least C++17 variants, and then move forward for > backward compatibility. > > The question is not C++17 variants vs. Bison variants, that's a detail. > The problem is a complete implementation of GLR in C++, instead of the > thin C++ wrapper around a C GLR parser as we have it today. That's > way more ambitious. > > > Or I thought about another feature. Something like attributes, that can > be attached to rules (for example, I can attach a needed type, like it > already implemented by variants in Bison — %type <my_type> rule1 ...), and > then in C++ code handling the rule I would like to read this attribute, to > access the value from C++17 std::any or std::variant. For example: > > > > %attr rule1 {type} > > ... > > rule2: rule1 {$$ = std::get<$a1>($1);} > > > > And yes, I want help with implementing C++ GLR variants. > > Sorry, I'm confused, and I don't understand what you mean. Maybe > you meant to say "nonterminal symbol" instead of "rule"?
