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

Jeff Vincent JVincent at Novell.Com
Thu Apr 22 10:52:13 PDT 2004


John, 
 
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.
 
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.
 
So I see the way I have done it as reducing variablity and simplifying
the parser, although I may be missing something.  Please clarify if you
feel so inclined.  I welcome any chance to rethink or revisit my code. 

 
Jeff

>>> johnm-antlr at non.net 4/22/2004 11:00:13 AM >>>

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

> The ifFalseblock will be null if the else is omitted.

Let me suggest that that is a mistake.  One of the guiding principles
of
managing complexity in a translator is to reduce variability.  I.e.,
go
ahead and create an imaginary, placeholder node such as
"EMPTY_FALSE_BLOCK".

[For the pattern minded in the audience, this is a variation of the
"Null
Object" pattern and the arguments of why this is a good idea follow
directly though it all comes down to simplicity. :-)]

Hope this helps,
        John





Yahoo! Groups Links






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20040422/331cc111/attachment.html


More information about the antlr-interest mailing list