[antlr-interest] Repeating output constructs with stringtemplates
Loring Craymer
lgcraymer at yahoo.com
Sat Sep 1 23:54:36 PDT 2007
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
More information about the antlr-interest
mailing list