[antlr-interest] Repeating output constructs with stringtemplates
Andy Tripp
antlr at jazillian.com
Fri Aug 31 12:04:07 PDT 2007
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);
>> }
>> }
>
More information about the antlr-interest
mailing list