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
