Re: GLR C++ Variants

[Сергей Фасман]

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 <address@hidden>:

> Hi,
>
> > Le 11 janv. 2020 à 10:38, Ookami <address@hidden> 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"?