[antlr-interest] philosophy about translation

[Andy Tripp]

Kay Roepke wrote:

>
> On 27. Oct 2006, at 16:44 , Andy Tripp wrote:
>
>> So what I'm doing is write a tree-matching class that allows you to  say
>> "v + x --> v.add(x)" to mean "look through an AST for a "+"
>> node with a first child that's an IDENT that has a particular text,  
>> and any arbitrary
>> second child. If found, replace that AST node with a different AST  node
>> that has a METHOD_CALL node as its root, a DOT node as first child,
>> etc."
>
>
> Like a parser rule with a rewrite action? Sounds tremendously like  
> it...;)

Yes, with the following differences:
* the "action" is always the same: "replace the matched pattern with 
this one"
* the "action" is not fired at particular place(s) in the tree during a 
treewalk, but
  rather fired by arbitrary Java code. (In my BigDecimal example, it 
only fires
  on expressions that contain a reference to some variable that I've 
just changed to
  BigDecimal type).
* the "v + x --> v.add(x)" specification is quite different syntax than 
a treewalker action.
* with the treewalker approach you'd be sure to "cover the whole input 
grammar", with
   this approach you wouldn't.

> I think a filtering parser (or even tree  parser with rewrite  
> ability) will be able to
> do just that!
> For some reason there's a voice in my head that says "you want to  
> write a translator from
> a more human-readable text input to ANTLR grammars". 

No I'm saying I want to write a translator *without* ever having to 
really know the
input and output language grammars and AST structures. I don't care how 
smart someone
is, I doubt they'll know what "a.add(1)" looks like as a C-AST, a 
Java-AST and a COBOL-AST.
And that's about as trivial a snippet of code as you'll ever see.

> Because this is  pretty much what you
> can do with ANTLR already, although not completely in ANTLR syntax.


I disagree. With ANTLR treewalkers or even any other tool and not 
treewalkers when you build
ASTs and then transform them to other ASTs, you have to be intimately 
familiar with the
shape of those ASTs (i.e. the grammar for the input and output 
languages). I'd rather not have
to know that. I know that the COBOL sentence:
ADD 1 TO A GIVING B.
...maps to the Java statement...
B = A + 1;

...and yet I have little clue as to what the COBOL or Java ASTs look like.
So I really do want to write:
ADD v1 TO v2 GIVING v3 --> v3 = v1 + v2;
...and never even think about AST structures.
If the underlying tool wants to use ASTs (or not), that's fine with me.

>
> Once ANTLR can support tree rewrites I don't see why you'd have to  
> resort to custom Java
> classes to reimplement that.

Is there some upcoming ANTLR "tree rewrite" feature I don't know about 
that's different from treewalkers?

> It seems to me that you are actually implementing a treeparser  
> generator, looking at
> "v + x ..." and your explanation of it. Just with a different (non- 
> EBNF) syntax. Is that a
> wise decision? I cannot really say, but I have the feeling that you  
> might open a can of worms
> there. Of course, I might also be totally wrong :)

Yes, I currently use token streams for my pattern matching, and I'm 
adding a similar thing that
uses similar syntax that works on ASTs instead. I'll keep you posted on 
any cans of worms :)

>
> If I was to tackle this problem, I'd try to actually generate some  
> sort of ANTLR grammar to
> do the actual tree walking for me, translated from my rule definitions.
> This could mean that I'd have to enhance certain aspects of ANTLR  
> (like implementing filtering
> parsers and treeparsers, tree rewrites), but in the long run that  
> would be worth it, I think.

What I have seems to be working fine after just one day of design and 
development. The
real test will come when I use it to replace C++ operator overloading. 
As I've said before,
I'm don't really see the benefit of treewalking as opposed to just 
walking the tree "by hand"
(via visitor pattern or otherwise). It's very few lines of code to check 
if a given AST "matches"
another AST...no need to get any ANTLR grammar involved.

Andy

>
> cheers,
> -k
>
>
>
>