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

[Hans Aberg]

On 17 Jun 2007, at 00:10, Michiel De Wilde wrote:

> Here is a "generic" analysis of Bison support required/useful for any
> "polymorphic-type-other-than-a-union" solution.
> (1) The definition of YYSTYPE/semantic_type as a polymorphic type
>    (usable like a union, but please not a real C union with its  
> limitations)
>    --> current support: a real C union{} or any user-defined type
> (2) A way to express the type of the semantic value of tokens and  
> nonterminals.
>    --> current support: the %token and %type clause indicating a
>        C union field between angular brackets
> (3) Automatic correct type selection (or enforcement) in actions
>    of objects of the polymorphic semantic_type.
>    --> current support: field selection of the union: yyval.type_field
> (4) Cleanup of dicarded (non)terminals
>    --> current support: %destructor which takes care of cleanup in  
> all cases
>        (but only those cases) that cannot be handled by actions
> (5) Defined behavior for rules without actions
>    --> current support: $$=$1, undefined behavior when there is no $1.

The only think that needs some substantial work is 5. as the typed  
form becomes $<type0>$=$<type1>1. Cleanup, as in 4, can be done via  
the C++ language, so %destructor is not needed. As before in 1, one  
just defines YYSTYPE to whatever type one wants. As for 3, as you  
note, the <type> just expands to a field selection yyval.type, and  
when using a C++ polymorphic class hierarchy, one may use (depending  
on model): static_cast<type>(f(yylval)) if the base class is not  
derived as virtual, or otherwise dynamic_cast<type> >(f(yylval)),  
where f is a function depending on implementation. So there are a  
number of models here, but it can be handled with some M4 macro, I  
think. As for 2, I haven't given thought to that, but such changes  
can be easily handled, as Bison uses .l and .y files for its grammar.

  Hans Aberg