[antlr-interest] New article on StringTemplates and Treewalkers

Andy Tripp atripp at jazillian.com
Tue Jan 10 14:29:04 PST 2006


>
>
>On Jan 10, 2006, at 1:14 PM, sohail at taggedtype.net <http://www.antlr.org/mailman/listinfo/antlr-interest> wrote:
>>/ I was struck by the example of 5 lines of C code being folded into one
>/>/ line of Java code. Why couldn't you have a tree parser do this? It  
>/>/ would
>/>/ be inefficient, but I don't know if that is the point of the article.
>/
>Hi.  My impression from reading his article was that Andy was  
>interpreting tree walker to be the simple visitor pattern where all  
>you can see is "I'm at node function definition" as opposed to the  
>more powerful grammar-based tree pattern matching:
>
>funcdef
>	: ^(FUNCDEF ID args body)
>	;
>
>Specifically he asked where one would worry about whether or not a  
>return statement was present in the body.  Seems straightforward to  
>have an action after the body rule reference that checked a boolean  
>set by body.  You might do this (using the new dynamic scope stuff):
>
>funcdef
>scope {
>   boolean hasReturn;
>}
>@init {
>   hasReturn = false;
>}
>	: ^(FUNCDEF ID args body) {if ($hasReturn) ...}
>	;
>
>body : stat+ ;
>
>stat : ... | ^(RETURN expr) {$funcdef::hasReturn=true;} | ... ;
>
>Andy, is this easier or harder than you imagined?  Does it address  
>your point?
>
>Ter
>

Ter,
If I understand you right, you've inadvertently proved my point exactly.
Your code above (if I read it right) only checks that the function 
contains at least one "return".
But it may find a return inside some "if", for example, whereas javac 
does static flow analysis
and will see that there exists a path through the function that does not 
end with a "return".
I mention this in my article.

So this answer is about the level of difficulty that I expected, but it 
doesn't do what it needs to.
Andy


More information about the antlr-interest mailing list