Michael Meskes <[EMAIL PROTECTED]> writes:
> Anyway, the problem is that some rules expand to either Iconst, FCONST or
> Sconst. So do I have to change all these rules? 

> Just changing the rule for Iconst and Sconst e.g doesn't work since
> AexprConst expands to the variable in two different ways. And bison
> certainly does not like that. 

It looks to me like you ought to try to clean up the not-very-consistent
treatment of constants in the grammar.  Some rules use raw ICONST, some
use Iconst, some use IntegerOnly --- ugh.  There's no need for all that
variation IMHO.

I'd think about making a small number of productions like

AnyConst: ICONST | FCONST | SCONST

IntegerConst: ICONST | - ICONST

StringConst: SCONST

and trying to make *all* the grammar's uses of constants go through one
of these productions.  For instance AexprConst would produce either
AnyConst or one of the cast-decorated variants.  Then, ecpg's grammar
would differ from the backend's grammar by adding ":variable" as an
alternative to each of this small group of productions.

The trick is to choose a good set of gateway productions; the above is
probably not quite right...

                        regards, tom lane

Reply via email to