[antlr-interest] philosophy about translation

Andy Tripp antlr at jazillian.com
Wed Oct 11 19:20:49 PDT 2006


>>>the gcc toolset.
>>>      
>>>
>>Huh??? That makes no sense to me. I've described
>>lots of things that are 
>>completely out of place in
>>a conventional compiler. A conventional compiler
>>doesn't translate 
>>library calls, like "printf" to
>>"System.out.println".
>>I do stuff like "strcpy(v1, v2) --> v1 = v2",
>>replacing a C strcpy() 
>>call with a Java assignment.
>>No conventional compiler does anything like that,
>>because technically, 
>>it's wrong!
>>    
>>
>
>Check out memcpy for gcc targeting an x86 for an
>example of a compiler-translated library call. 
>
I don't need to check what gcc does for memcpy() calls. I know it does the
same thing that it does for all function calls: generates low-level code
to call a function. You're missing my point entirely: I don't "compile"
a memcpy() and all other calls down to a lower level - I treat each
one individually. For memcpy(), for example, I do all that checking
to see what a reasonable replacement is.

>As for
>the assignment, I see nothing wrong; you have added
>the restrictions that all strings are read-only.  That
>would cause errors if naively translated statements
>like "v1[5] = ' ';", but I assume that you do the
>right thing.
>  
>
strcpy() actually makes a copy, while assignment does not. That
can introduce a bug. A compiler would never do that type of replacement
because it may introduce a bug. Yet a person doing a rewrite would.

And no, don't assume that I do "the right thing". Your idea of the 
"right thing" is, I'm
sure, to generate code that always works. And that's not what I do. If I 
did that,
I would end up with Ephedra, allocating a huge array in memory, and having
every variable reference go through that array.

>  
>
>>I rename files, methods, and variables based on
>>user-specified mappings. 
>>Compilers don't do that.
>>I could go on.
>>    
>>
>
>Most of the translations are not user-specified, true.
> But any C/C++ compiler renames methods and variables
>according to user specifications (macros), and
>supports file renaming for output.
>
Yea, but that's different. If you convert 1000 files from C to Java, you
want to specify a mapping from each input file name to the package that
the Java class should go into.

>  
>
>  
>
>>>As to your "unconventional" approach:  I hate to
>>>      
>>>
>>say this, but 
>>    
>>
>>>everything that you have described doing is well
>>>      
>>>
>>documented in the 
>>    
>>
>>>literature.
>>>      
>>>
>>Maybe you could point me to something specific.
>>Today I'm adding smarts 
>>to my GotoRemoverRule that generates code that
>>is not faster or more compact than what it was
>>producing before, but it 
>>looks better to the human eye. I doubt that
>>there's any literature on that.
>>    
>>
>
>That sort of thing is usually isolated to "see what I
>can do" claims in papers.  Compiler-generated
>assembler files are usually quite readable (well, for
>assembly language) and that dates back to the days
>when it was necessary to claim that "FORTRAN-generated
>assembler is as good as (or nearly as good as)
>programmer-generated code".
>  
>
All I can say is that every time I've tried any language-to-language 
translator on
"hello, world", the output always comes to about 50 lines of code. In the
grammar-to-parser-generator field,
lex and yacc produce awful code, and ANTLR produces quite readable code.
If anyone knows of any language-to-language translators that produce
"readable" code, I'd love to hear about them.

>  
>
>>>I have noticed that "healthy disrespect for
>>>      
>>>
>>conventional approaches" 
>>    
>>
>>>usually translates to "I never check to see if I
>>>      
>>>
>>am reinventing the 
>>    
>>
>>>wheel or not".  One of the great resources on the
>>>      
>>>
>>web is Citeseer:  
>>    
>>
>>><http://citeseer.ist.psu.edu/>.  It has some of
>>>      
>>>
>>the good early papers 
>>    
>>
>>>on pattern matching and transformation systems.
>>>      
>>>
>>I've looked at many, many papers on those. Can you
>>point me to anything 
>>specific that you
>>think I'm missing?
>>    
>>
>
>No, sorry, you'll have to do your own research.  I
>never have enough time to do as much as I would like
>for myself!
>  
>
OK, well, you're telling me that every issue I raise has been covered
"in the literature", and I think I've made a reasonable attempt to find it,
and haven't found anything.

>  
>
>>I've also noticed that the person who feels like
>>they're "breaking new 
>>ground" just hasn't done his homework. That's why
>>I spend so much time typing here - worried that I
>>might be doing that. 
>>So I'm not just being defensive,
>>
>>    
>>
>
>This is a user group, not a theory group, so it is not
>the ideal forum for this sort of sanity check
>(although it is certainly better than none).  I do
>have to think that dragging Monty out of  the woodwork
>for this discussion was a significant achievement! I
>only jumped in after I thought that sanity had
>prevailed to make the point that "it's really not the
>methodology that's at issue, it's the level of tool
>support".
>
>--Loring
>=== message truncated ===
>  
>
Thanks for the discussion. If you can suggest a better place for me to bring
stuff like this up, let me know and I'll take it elsewhere.

Andy

>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>  
>



More information about the antlr-interest mailing list