Re: %union errors that shouldn't be there

[Laurence Finston]

On Sun, 20 Mar 2005, DYP wrote:

> My %union is declared in the following way [...]
>
> %union{
>              float fconst;
>              int type;
>              astNode* node;
>              string* name;
>              nodeList* list;
>        }
>

If you don't mind an unsolicited suggestion, you might want
to consider using a `void*' instead of three different
pointer types in your `%union' declaration.  This would make
it possible to simplify your `%token' and `%type'
declarations, and you'd be able to use a pointer to any type
as the semantic value of a given token without changing the
`%union' declaration.

For example, this is my `%union' declaration:

@=%union@>
{
  char string_value[64];
  double real_value;
  signed int int_value;
  void* pointer_value;
};

These are two `%type' declarations for non-terminal symbols:

@=%type <pointer_value> point_primary@>@/
@=%type <pointer_value> path_primary@>@/

The semantic value of a `point_primary' symbol is a pointer
to an object of type `class Point', cast to `void*', whereas
that of a `path_primary' symbol is a pointer to an object of
type  `class Path', cast to `void*'.  The pointers must be
cast to the proper type in the rules, but this is always
clear.  For example, in the rule
`path_primary: SUBPATH numeric_list OF path_primary',
`$4' can only be a `Path*', cast to `void*'.

In my next parser, I will probably simply use `void*' as
`YYSTYPE' and not bother with `%union'.  In this one, it is
convenient to let the parser code generated by Bison take
care of allocating and freeing memory for the other members
of the `union', but this must be weighed against the
simplicity of being able to treat all objects representing
semantic values in the same way.  There are also issues
involving the `%destructor' feature and error recovery.

Laurence