[antlr-interest] if-then-else - Grammar generates faulty parser code

[John D. Mitchell]

>>>>> "Jeff" == Jeff Vincent <JVincent at Novell.Com> writes:
[...]

> I'm not sure I follow exactly, or maybe misunderstanding what you said.
> I create an imaginary token called "COMBO" that could have no siblings
> (equivalent to EMPTY_BLOCK).  I didn't think it should be necessary to
> create a token specifically to represent "EMPTY_BLOCK" since null works
> just fine and from my perspective, denotes exactly what I want.

Check out the literature on the Null Object pattern.


> This has allowed me to just have one generic AST build rule that handles
> all cases (for the "IF").  I don't have to add additional code to check
> for "EMPTY_BLOCK" in order to then insert a special imaginary token.
> From my non-purist point of view it seemed simple and straight forward
> and works without issue.

Ah, but the single place that you're saving work in the parser makes for a
more complicated tree that may end up being used/traversed/etc. multiple
times.

Obviously, in your specific example, it sounds like you (currently) only
have a single TreeExecutor pass.

Hope this helps,
		John


 
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/