[antlr-interest] template generation for dumb rules

[Loring Craymer]

How about just returning an argument list?  The typical use of  "don't know" items is to pass them as a list argument to a higher level template where they might be invoked in a template as <args; separator = " "> to process them en masse.  Textual concatenation here is often premature.

--Loring

----- Original Message ----
From: Terence Parr <parrt at cs.usfca.edu>
To: Grzegorz Cieslewski <cieslewski at hcs.ufl.edu>
Cc: antlr-interest at antlr.org
Sent: Tuesday, March 25, 2008 12:07:48 PM
Subject: Re: [antlr-interest] template generation for dumb rules


On Mar 25, 2008, at 10:14 AM, Grzegorz Cieslewski wrote:
> I think that the concatenating two templates would be an optimal
> solution.  I have many rules that consist of 2 or more sub-rules.  If
> the user does not like the default rule he can overwrite it with his
> own,  which in my opinion is better than adding many simple templates
> just to get a token to print that is nested 20 rules down. Also, this
> would make it similar in behavior to the AST rewriting approach where
> you don't have to specify a rewrite rule to get a tree back.

Agreed...but what about

d : id (',' id) ';' ;

what should i produce here? In other words, when do I stop doing the  
default behavior and force you to say how it works?  Do i even put in  
the literals into the result template?  Maybe.

> Since that would change the default behavior of the ANTLR, I think
> that adding another option like "use_default_template=true" or
> something would make life easier.

Well, I'll probably just add the default behavior...now they would get  
nthing so adding it would be ok, i just don't really know what answer  
is yet.  I suppose cat'ing each element with <stuff> template would be  
ok.

Ter






      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080325/17438420/attachment.html