At 18:12 +0000 2005/03/06, Derek M Jones wrote:
>> 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).
Paul Hilfinger is thinking about actions that during a split are executed
immediately, in addition to those delayed until the merge. This will enable
the kinds of things that you are asking for, I think, as one then can build
the parse trees, and make a selection based on that.
Otherwise, you seem to simply ask for nondeterministic parsing, where one
keeps track of all the parsing possibilities. Such parsers are not difficult
to write, see for example the Parsing Techniques book:
http://www.cs.vu.nl/~dick/PTAPG.html
Such parsers are especially easily written in a functional language, like
Haskell <http://haskell.org>. If you check the Haskell site, or list, you
might find one for you. The problem is though that these are very slow, with
stress on very: In once replaced one with a Flex-Bison combination (on the
Mini-Prolog that comes with Hugs), and a very slow program became lightning
fast. But with your problem at hand, you may have no choice.
Hans Aberg
_______________________________________________
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
