Tyson@SRI-AI.ARPA@sri-unix.UUCP (08/21/83)
From: Mabry Tyson <Tyson@SRI-AI.ARPA> Some of the comments on Lisp-to-Lisp translation seem to be rather naive. Translating code that works on pure S-expressions is usually not too difficult. However, Lisp is not pure Lisp. I am presently translating some code from Interlisp to Zetalisp (from a Dec-20 to a Symbolics 3600) and thought a few comments might be appropriate. First off, Interlisp has TRANSOR which is a package to translate between Lisps and is programmable. It isn't used often but it does some of the basic translations. There is an Interlisp Compatability Package(ILCP) on the 3600, which when combined with a CONVERT program to translate from Interlisp (running in Interlisp), covers a fair amount of Interlisp. (Unfortunately it is still early in its development - I just rewrote all the I/O functions because they didn't work for me.) Even with these aids there are lots of problems. Here are a few examples I have come across: In the source language, taking the CAR of an atom did not cause an error. Apparently laziness prevented the author from writing code to check whether some input was an atom (which was legal input) before seeing if the CAR of it was some special symbol. Since Interlisp-10 is short of cons-cell room, many relatively obscure pieces of code were designed to use few conses. Thus the author used and reused scratch lists and scratch strings. The exact effect couldn't be duplicated. In particular, he would put characters into specific spots in the scratch string and then would collect the whole string. (I'm translating this into arrays.) All the I/O has to be changed around. The program used screen control characters to do fancy I/O on the screen. It just printed the right string to go to whereever it wanted. You can't print a string on the 3600 to do that. Also, whether you get an end-of-line character at the end of input is different (so I have to hand patch code that did a (RATOM) (READC)). And of course file names (as well as the default part of them, ie., the directory) are all different. Then there are little differences which the compatability package can take care of but introduce inefficiencies. For instance, the function which returns the first position of a character in a string is different between the two lisps because the values returned are off by 1. So, where the author of the program used that function just to determine whether the character was in the string is now computing the position and then offsetting it by 1. The ILCP does have a nice advantage of letting me use the Interlisp name for functions even though there is a similarly named, but different, function in Zetalisp. Unfortunately for me, this code is going to be continued to be developed on the Dec-20 while we want to get the same code up on the 3600. So I have to try to set it up so the translation can happen often rather than just once. That means going back to the Interlisp code and putting it into shape so that a minimum amount of hand-patching need be done.
sts@ssc-vax.UUCP (Stanley T Shebs) (08/24/83)
These problems just go to show what AI people have known for years (ever since the first great bust of machine translation) - ya can't translate without understanding what yer translating. Optimizing compilers are often impressive encodings of expert coders' knowledge, and they are for very simple languages - not like Interlisp or English stan the lep hacker ssc-vax!sts (soon utah-cs)