[plt-scheme] Question about parser.ss

The (suppress) option to the parser tells it to not report any conflict 
warnings.  There isn't a way to tell it to not report these particular 
conflicts, but to still report others.

-Scott

On Wednesday 12 January 2005 02:36 pm, Jean-Pierre Lozi wrote:
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> 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.