[antlr-interest] philosophy about translation

Andy Tripp antlr at jazillian.com
Fri Oct 27 07:44:49 PDT 2006


>
> To briefly return to the topic ;), if you are doing source-to-source  
> translation, I would love to see a product that let's me see the  
> effect of one certain rule not only by the grammatical structure of  
> the (ENBF-)rules that drive it, but also by some form of  
> visualization that let me see the big "picture" without having to  
> simulate the parser/translator in my head. I am convinced that a  
> visual representation of this process would speed up my work  
> tremendously. 

Yes! Suppose we're changing a "long" variable to be "BigDecimal".
So, for example, "i + 3" becomes "i.add(3)".
I'd rather have a set of rules that look like this:

v + x --> v.add(x)

...than the correct-but-nontrivial tree version:

PLUS
  v
  x
-->
METHOD_CALL
   DOT
      v
      add
   ELIST
      x

I'm sorry, but I just didn't know, off the top of my head, what the AST 
for "v.add(x)" looks like.
I'm going to be writing at least 10 of these sorts of "pattern 
replacements" just for this BigDecimalRule
alone, and I refuse to get bogged down in mental images of ASTs.

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."

Humans think in terms of token streams, translators can go ahead and 
implement
the humans' wishes in terms of nicely structured trees.


More information about the antlr-interest mailing list