[antlr-interest] Repeating output constructs with stringtemplates

[Andy Tripp]

Terence Parr wrote:
>
> On Aug 30, 2007, at 3:26 PM, Andy Tripp wrote:
>
>> Hoping back onto my "vanilla library code is better than clever 
>> syntax" soapbox,
>
> Hi Andy.  so DSLs are bad?  
I generally don't like DSLs. You've got to remember that I (and most 
people, I think) often have to
*read* DSLs, while you almost always are the *writer* (designer) of the 
DSL. I wonder how long
it would take someone to figure out your one-liner of ST code (given a 
realistic context - he encounters
it in the middle of some code somewhere), compared to my Java code.
> We should all go back to Pascal or assembly?  OO is good, but 
> functional is bad?  I can't imagine how
>
> decl(type, names) ::= "<names:{ n | <type> <n>;}>"
>
> is not superior to your code. I have to imagine the emergent behavior 
> in code.  In my template, it says...well, "here's the output".  A 
> document with holes in it.  Gotta learn the syntax like you had to 
> learn Java.
I frown on people using Latin simply because so few people speak it, not 
because it's not easier to
express myself once I learn it. You could say "well, you just need to 
learn Latin as  you did English".
I guess that's true, but I don't really enjoy learning other languages - 
too busy/dumb for that :)
>
> You should also argue against parser generators if you're against 
> unparser generators ;)
Parser-generators are nice because they reflect the input language so well.
A grammar says "here is what my input language looks like; make a tree 
out of that input".
On the other hand, converting a tree back to code is quite a different 
problem.
This:
   decl(type, names) ::= "<names:{ n | <type> <n>;}>"
gives me no hint at all about what its input looks like (the tree 
structure) or what its output (c0de) looks like.
Neither does the Java code below, I admit.

Ideally, I'd like to be able to write something like this:

parent
   DECL
     type
     child1
     ...
     childN

->
parent
   DECL
      type
         child1
      ...
      type
         childN

I guess that's what I was expecting from a "tree transformation tool" 
tools like XSLT and TXL :(
Andy    

>
> Ter
>
>> void splitUpDeclarations(MyAST decl) {
>>     MyAST parent = decl.getParent();
>>     int insertLocation = parent.indexOfChild(decl);
>>     MyAST type = decl.getChild(0);                 // first child
>>     List<MyAST> vars = decl.getChildren(1);  // rest of children
>>     for (MyAST var: vars) {
>>         MyAst singleDecl = new MyAST(DECL);
>>         singleDecl.addChildren(type.clone(), var);
>>         parent.insert(insertLocation, singleDecl);
>>     }
>> }
>