Hans, >You ignore the context information distinguishing between type-names and >number-names. So set these names equal to the same token, and let the GLR >parser handle it. It then produces all correct parses, including the >possible type-name/number-name choices.
This is what I am already doing (I have no choice since there is no symbol table). > You then get the correct parse >trees, and need only decide how to select one over the other. Clearly, this >choice cannot be done, in general, unless you somehow supply the context >information missing. Unfortunately glr parsing is not a universal solution. It requires that at the end of processing there be a unique parse tree (the multiple parse trees that may exist while processing the input tokens are required to eventually resolve to a single parse). The %dprec option allows the grammar writer to select which parse to use in some circumstances (i.e., both parses must involve the same sequence of tokens), but not all. I am current trying to figure out why (x) + (y) + z; (which can be parsed in four different ways) is generating an ambiguity (it should be handled by my existing uses of %dprec and grammar rewrites) derek -- Derek M Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:[EMAIL PROTECTED] Applications Standards Conformance Testing http://www.knosof.co.uk _______________________________________________ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison