Re: A polymorphic YYSTYPE for C++ (instead of the %union)

[Michiel De Wilde]

Hi Hans and Paul,

I'll reply to both of you in this mail.

Paul:

> How much is this patch tied to Boost?  Can it be used easily with other C++ 
> libraries?

You need any polymorphic type (one that can hold objects of a number
of types AND properly destruct them). I chose boost::variant as it is
very clean and simple to use. If you want to customize the choice of
"variant type", 4 items need to be adjustable:
- the header to include [#include <boost/variant.hpp>]
- the typedef of semantic_type [boost::variant<int,std::string,...>]
- how to assign an object of a given type to a variant object
[boost::get<int>(yyval) = ...]
- how to extract an object of a given type from the variant object
[boost::get<int>(...)]

That said, Boost is quite "standard" as it is very closely connected
to the C++ standardization process for new C++ features.

> What sort of documentation should appear in the Bison manual?

Some addition to the section on C++ parsers. I'm willing to write some
documentation (after we have consensus).

> Why is there a limitation on what types can appear?  (They can't have angle 
> brackets, apparently.)  Can this limitation be removed?

I haven't really checked whether the limitation actually occurs in
practice, but you see the potential problem in this example:
%type <std::list<int> > resultlist

We only need to make sure that the lexical scanner of the grammar file
(src/scan-gram.l?) properly tokenizes the type expression instead of
stopping at the first closing angle bracket ("<std::list<int"). The
scanner could keep a count on the angle brackets (just as is done with
braces).

Hans:

> There is no change needed: I have used a standard C++ polymorphic class 
> hierarchy for years

I'm very interested. Could you provide an example grammar? How do you
use the safety-providing automatic type selection feature of Bison in
this case (the equivalent of automatically choosing the right field of
the %union)?

> A typed replacement of %union: Then I think the problem is with the default actions, 
> which no longer can be collected to a single entry in the parser "switch" 
> statement.

Very true. I've addressed this by outputting a muscle (in
src/output.c) providing C++ code that is executed right before a
reduction action. It initializes the yyval variant to a
default-constructed object of the right result type.

By the way, I've not used the "%union" construct for the definition of
the different types as I saw no way to get rid of the braces in the
generated muscle. Personally I think that the "%define variant"
approach is a fairly clean solution.


In any case, thank you for the quick reply to my submission. I
sincerely hope that this or another solution will make it to the next
release of Bison (so we finally get rid of manual object destruction).
Further comments/test results are very welcome!

Kind regards,

Michiel

2007/6/15, Hans Aberg <address@hidden>:
> On 15 Jun 2007, at 18:12, Paul Eggert wrote:
>
> > Thanks for the patch that you proposed in
> > <http://lists.gnu.org/archive/html/bison-patches/2007-06/
> > msg00000.html>.
> > I don't use C++, so you'll have to bear with me on some dumb
> > questions.  Perhaps some other contributor who knows C++ well can also
> > chime in.
> >
> > * How much is this patch tied to Boost?  Can it be used easily with
> > other
> >   C++ libraries?
> >
> > * What sort of documentation should appear in the Bison manual?
> >
> > * Why is there a limitation on what types can appear?  (They can't
> >   have angle brackets, apparently.)  Can this limitation be removed?
>
> If one cannot use the type system that comes with %union, there is
> not change needed: I have used a standard C++ polymorphic class
> hierarchy for years. The only problem was some code placement, but
> has has been fixed with the extension of %define that Akim fixed.
>
> Akim has been thinking of variants as typed replacement of %union.
> Then I think the problem is with the default actions, which no longer
> can be collected to a single entry in the parser "switch" statement.
> And if this part is being fixed, one can just well just introduce a
> M4 macro, admitting variants as well as a standard C++ polymorphic
> hierarchy, I think.
>
>    Hans Aberg