[antlr-interest] if-then-else - Grammar generates faulty parser code
John D. Mitchell
johnm-antlr at non.net
Thu Apr 22 12:58:26 PDT 2004
>>>>> "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/
More information about the antlr-interest
mailing list