[plt-scheme] Question about parser.ss

I'm writing a BASIC interpreter with the lexer.ss / parser.ss modules 
provided with drscheme. I use 3 kinds of expressions, i.e. boolean 
expressions, string expressions, and numeric expressions. My code looks 
something like :

(parser
 (...)
 (grammar
 (...)
 ((string-expression)
   ((string-expression + string-expression) (...)))
 ((number-expression)
   ((number-expression + string-expression) (...)))
 ((boolean-expression)
   ((boolean-expression + boolean-expression) (...)))
 (...))

(Where (...) does not mean anything but "some code").

I need a mixed type of variables, i.e I need mixed-expressions, which, 
when read, can either be boolean-expressions, number-expressions, or 
string-expressions. I mean, something like this :

(...)

((string-expression)
 ;; A mixed type of expression
 ((mixed-expression) (...))
 (...))

((number-expression)
 ;; A mixed type of expression
 ((mixed-expression) (...))
 (...))

(...)

BTW, the compiler complains, worrying about reduce/reduce conflicts. But 
the point is that for this particular kind of expressions, the way it is 
interpreted (ie as a string or as a number, for example) does not matter 
at all. I will convert them the same way in every expression type, for 
example as `(*mixed-expr* ,$1).

I know that perhaps, it would be a better idea to create the 
mixed-expression type just like all the others, but for example, into 
the number-expression statement, I define functions like 
(numeric-expression + numeric-expression), and I would like any 
mixed-expression to be recognized by the parser as well as a numeric 
expression.

The two only solutions to this issue I see are :
    * Either add a huge number of line, with the mixed-expressions, in 
order to force the parser to admit them (e.g. (mixed-expression + 
numeric-expression), (numeric-expression + mixed-expression)).
    * Or rewrite the whole syntax with no types at all, which I surely 
won't do.

All I need is a way to stop the parser complaining about reduce/reduce 
conflicts for this particular case, as every reduction breeds to the 
same parser translation.

Any help or ideas are welcome.

-- 
Jean-Pierre Lozi
http://mreddesigner.lozi.org