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

[Monty Zukowski]

Jeff,
	You have a unique situation in that your tree parser actions are your 
runtime and you call them to "execute" the script you have parsed.  
Actually that's pretty clever -- (NOTE TO TERENCE) we (ahem, as I 
recall) haven't given much thought to how to create interpreters with 
ANTLR beyond "do it in the actions."  This merits attention at the next 
ANTLR Cabal to refine ANTLR 3 designs.

	Loring and I have been trying to distill comprehensive guidelines to 
tree building.  We've been examining the "EMPTY_BLOCK" placeholder node 
trick.  The tradeoff is computation v. space but also introducing a 
placeholder node may be required to eliminate ambiguity to support 
something like the C "for" -- for: #(FOR e1:expr e2:expr e3:expr)--if 
you made the expr's optional then you would need some other sentinel 
such as leaving in the semicolon so you knew which place the expr was 
in to accommodate for empty exprs.

	But without an ambiguity it really becomes space v. code size.  
Ideally we(I)'ll come up with a number of distinct scenarios and work 
them in different styles to really nail down the tradeoffs.

Monty Zukowski

ANTLR & Java Consultant -- http://www.codetransform.com
ANSI C/GCC transformation toolkit -- 
http://www.codetransform.com/gcc.html
Embrace the Decay -- http://www.codetransform.com/EmbraceDecay.html

On Apr 22, 2004, at 10:52 AM, Jeff Vincent wrote:

>
> 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. 


 
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/