[antlr-interest] philosophy about translation

[Andy Tripp]

>
>  well you have to store the data in some way and recording the  
> grammatical structure by encoding it in the structure the tree seems  
> useful regardless of what you're doing.  Better than a linked list of  
> the input tokens right?   I guess you are saying you don't really  
> care about the data structure because you are doing a declarative  
> rule-based translation.

Right. I'm using a List of Tokens, and it works great for me. I think of 
"public static void main(String[] args)" as a sequence
of 8 tokens. That's a much simpler mental picture (at least for me) than 
whatever AST that parses to.

>
>   I agree that the declarative approach works best in many  
> situations.  On the other hand, I am not sure that what you say in  
> your article is that bad: "part of your work is being done with  
> treewalking, and part is done at the end."

I just know that for my app, the treewalking almost always seems more 
difficult than the alternative (which is sometimes
declarative, and sometime just "code that does the job"). One exception 
is expressions: when I need to parse a
conditional expression to change it from a "int" type to a "boolean" 
type, I use an AST, for example.

>
>  one of my big problems though with the declarative approach is that  
> you can easily generate an infinite loop.  I believe this is nicely  
> formalized in many of the papers done by the declarative approach  
> people and is the raison d'etre for Stratego that tries to let you  
> specify what the order of evaluation is for applying rules.  You can  
> clearly get a situation where you loop forever.  Of course, I suppose  
> that you can simply look for where the loop is by tracing the rule  
> applications, but anyone who is programmed in prolog says that it's  
> very difficult to debug when your list of rules doesn't work.

Yes, that's a problem. Ordering of phases is a huge problem too.
But at least I can deal with these problems...I couldn't seem to even 
get going with initial design/development
using the treewalking approach.

>
>>> I was raving about this like 7 years ago, it just totally rocks!
>>> Check the archives for my posts about multiple tree grammars, or ask
>>> questions if something isn't clear.
>>>
>>> By the last pass, I had a completely vb tree, and then I finally
>>> dumped it to text.
>>
>>
>> I had looked very carefully at all your stuff when I started 4  years 
>> ago.
>> My feeling is that if you're going to do a "natural" translation -  
>> that is:
>>
>> String hello = "hello";
>> String world = "world";
>> printf("%s %s\n", hello, world);
>>
>> ...becomes...
>>
>> System.out.println("Hello World");
>>
>> then the "walking the AST" approach doesn't come close to working.
>> The two ASTs for those two code chunks
>> have almost nothing in common, and doing that translation
>> is 1% a "tree-manipulation" problem, and 99% a "code mapping" problem.
>
>
> I think I disagree.  Somehow  you have to find these patterns whether  
> you're looking at the symbol table that was previously populated or  
> you're walking looking at the flow trying to figure out the variables  
> are.  

But the problem is that many phases can update the symbol table. Every 
time you move a variable declaration
from one place to another, rename a variable, change its type or its 
initial value or modifiers. So I've found that
generally, instead of a symbol table, it's better to just have code that 
can search through the code as it currently
stands and find the variable declaration and examine it.

I don't mean to come out against symbol tables in general, just in this 
case.

> Just for the record I am opposed to the translation you show  here.  
> That is not at all what I would expect unless it's clear that  those 
> variables are always constants.


Ahh...and therein lies the difference in our approaches. It's not what 
you'd *expect* because of your background
in language tools. But is it what you'd *want* as a customer who wants 
to replace C code with Java? Answer: customers
don't want "JOBOL", and they don't want "Cava". (Although, if they do 
want C in Java clothes, there's
a tool for that: http://ovid.tigris.org/Ephedra/)

>
>
>> I think if tree-walking works for most of the translation work, you  
>> either
>> have two very similar languages, or your output code looks just  like 
>> your
>> input code with different syntax. "I don't want 'JOBOL'", as one of my
>> customers said :)
>
>
> heh heh heh...yes, very interesting point.  I was very happy with my  
> annotate the tree approach for mantra which yields like
>
>     mlist c = mArrayList.of((
>     new Object() {
>       public mstream value(final mstream _input) {
>         mint i = new mint(0);
>         mlist _data = new mArrayList();
>         _input.start();
>         while (_input.more()) {
>           mstring n = (mstring)_input.next();
>           if ( (n).notEquals((new mstring("Tom"))) ) {
>           mobject _result = null;
>           _data.add(_result);
>           }
>           i = new mint(i.v+1); // huge waste
>         }
>         _input.stop(); // put this in a finally
>         mstream _str = new mListStream(_data);
>         return _str;
>       }
>     }
>     )
>     .value(((mobject)names).toStream()));
>
> from the simple looking:
>
> list c = names:{string n, n!="Tom"};

Hehehe...yup. A large part of my time is spent going the other way. 
Many, many times,
you have 20 lines of C code that should (in my view) be replaced with 
one line of Java.
Actually getting that to work in a general way is fun but close to 
impossible.

>
>  naturally, this was easy because even though it's big it's still a  
> one-to-one mapping, albeit with a complicated template.
>
> I am very much warming to your ideas about the declarative approach,  
> although the pure declarative approach is not something that has  
> proven popular with users.  All of the large tools that do this sort  
> of thing are so collocated that programmers won't use it.  Your  
> specific declarative system seems very nice and I would like to see  
> more of it some time.

Cool. Keep up the great work! I'm a slow adopter, but I am looking 
forward to v3.
COBOL seems to have been built for infinite lookahead :(

Andy

>
>
> Ter
>
>