[antlr-interest] Storing ambiguity in the tree

[Bryan Ewbank]

Alexey, others,

I'm doing the same thing - for me, it was forced because the new language
requires support for user-defined infix operators (with differing precedence
and arity - ugh).  That means I have a pass that does precedence after the
pass that does type analysis.  On the up side, it greatly simplifies the
parser grammar:

	EXPR : ( operator | terminal )* { ## = #( [EXPR,"EXPR"], ##); }
		// EXPR node is to provide a hook for precedence pass.

To take this further, I'm also recognizing if/else as separate entities,
then rejecting (as a semantic error) any else-statement without a leading
if-statement.

I'm working also on a paper on this, titled something like "precedence ain't
parsing", that will hopefully end up on antlr.org someday.

- Bryan Ewbank
"The best tool for requirements analysis and design is a crayon" 


Alexey Demakov said:
> My idea is to build some "flat" tree for ambiguous portions 
> of input, i.e. all input tokens should be children of one root node.
>
> So at the second pass we can run parser on list of children 
> and build subtree. It's only idea, I can't get you more details
> on implementation now.



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/