[antlr-interest] Repeating output constructs with stringtemplates

[Loring Craymer]

Hmm.  Obvious advertising sound bite:
"BNF.  The one DSL that Andy Tripp uses."

--Loring

--- Andy Tripp <antlr at jazillian.com> wrote:

> 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);
> >>     }
> >> }
> >
> 
> 



       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz