[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