[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