Number: 136

Date: 17-Mar-84  0':24':45

Submitter: Masinter.PA

Source: Hedrick@Rutgers

Subject: Want Common Lisp compatibility package

Assigned To: 

Attn: Lisp

Status: Open


Problem Type: 

Impact: Serious

Difficulty: Very Hard


Priority: Perhaps

System: Programming Environment

Subsystem: Other

Machine: 1108


Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Sannella.PA" "25-Sep-84 12':36':41" Subject': Status':(Wish->Open) Impact':(Moderate->Serious) Difficulty':(->Very% Hard) Description':]

Description: '
Received': from RUTGERS.ARPA by PARC-MAXC.ARPA; 12 MAR 84 12':51':54 PST'
Date': 12 Mar 84 13':44':45 EST'
From': Charles Hedrick <HEDRICK@RUTGERS.ARPA>'
Subject': Common Lisp'
To': masinter.PA'
Some of our users are becoming worried about the fact that ARPA seems'
to be pushing Common Lisp these days.  Do you know whether anybody'
is working on Common Lisp (either native or a compatibility package)'
for the Dandelion?'
Received': from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 21 MAR 84 18':17':22 PST'
Return-path': <@SUMEX-AIM.ARPA'>'
Redistributed': Xerox1100UsersGroup↑.PA'
Received': from PARC-GW.ARPA by SUMEX-AIM.ARPA with TCP; Wed 21 Mar 84 17':41':02-PST'
Received': from by ; 21 MAR 84 17':41':15 PST'
Date': 21 Mar 84 17':34 PST'
Subject': Re': Common Lisp compatibility'
To': schoen@sumex-aim.ARPA, 1100users@sumex-aim.ARPA'
Eric -'
	Yes, I''ve written a bidirectional Franz(Mac)Lisp <-> Interlisp'
translator, called Odradek.  Briefly': it''s a program written in Prolog'
that has/is a database of equivalent constructs in the two dialects.'
Odradek descends recursively through your code, translating merrily as'
it goes.  It works well.'
Unfortunately, the code belongs to my ex-employer; I can''t give you a'
copy.  If you know Prolog, it shouldn''t be hard to write.  In fact, I'
had it running within an hour of its conception.  I''d be happy to'
explain how to write something similar.'
Received': from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 22 MAR 84 05':35':16 PST'
Redistributed': Xerox1100UsersGroup↑.PA'
Received': from BBNG.ARPA by SUMEX-AIM.ARPA with TCP; Thu 22 Mar 84 04':54':03-PST'
Date': 22 Mar 84 07':54 EST'
Subject': Re': Common Lisp compatibility'
Cc': 1100users@SUMEX-AIM.ARPA'
Message-ID': <[BBNG]22-Mar-84 07':54':52.GREENFELD>'
In-Reply-To': The message of Sat 17 Mar 84 20':36':10-PST from Eric Schoen <Schoen@SUMEX-AIM.ARPA>'
We did a small translator of Interlisp to CommonLisp when we were'
evaluating delivery vehicles.  It wasn''t too hard, but was just a'
hack, tuned for translating our testing programs.  We would also'
be interested in a carefully done program, or might get around to it'
ourselves someday.'
Received': from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 24 MAR 84 08':52':07 PST'
Redistributed': Xerox1100UsersGroup↑.PA'
Date': Sat, 24 Mar 84 08':07':01 PST'
From': Eric Schoen <Schoen@SUMEX-AIM.ARPA>'
Subject': Re': Common Lisp compatibility'
To': 1100users@SUMEX-AIM.ARPA'
My thanks to all who responded regarding my questions about machine'
translation of Interlisp programs into Common Lisp.  I''ve tried to'
answer a couple of you directly, but have had mailer problems.  The'
best bet seems to be TRANSOR or a TRANSOR-like program to handle direct'
translation of the obvious differences (e.g. name changes, argument order,'
etc).  While there are no Interlisp to Common Lisp transforms, I did'
not find it too hard to create my own.'
I was hoping that someone explicitly handled CLISP I.S. OPR statements.'
Using CLISP itself to pretranslate these statements into "purer" Lisp'
is acceptable, but defeats the purpose of permitting the intent of the'
code to be clear.  It would be nice to translate to some form of (DO ..).'
The remaining problems I have at this point are thus the I.S. OPRS and'
Interlisp comments.  An EMACS keyboard macro could probably take care of'
turning the latter into semicolon prefixed lines of text.'
Note on TRANSOR': The PRESCAN function was almost entirely ASSEMBLE code'
for speed in Interlisp-10.  I''ve built an Interlisp-D version under '
(SELECTQ (SYSTEMTYPE) ..) and will forward the new code to Pasadena for'
inclusion in future LispUsers releases.'
Received': from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 25 MAR 84 05':47':33 PST'
Redistributed': Xerox1100UsersGroup↑.PA'
Received': from BBNG.ARPA by SUMEX-AIM.ARPA with TCP; Sun 25 Mar 84 05':10':52-PST'
Date': Sun, 25 Mar 84 08':12':23 EST'
Subject': Transor'
To': 1100users@SUMEX-AIM.ARPA'
Does the author of a program have any natural authority whereby to declare it'
hopelessly obsolete, and encourage others to write a better one? We need one,'
to judge from the previous messages, but TRANSOR should be flushed. Let me'
suggest the following to anyone who might like to write and document a new one.'
(1) Don''t use the editor at all.'
(2) Don''t imagine that translation is a one-shot computation. In practice one'
keeps on finding more transformations which should have been included.'
Therefore,  do not regard translation as editing in'
place, destructively, but as copying from some suitable property like SOURCEXPR'
to the function cell or EXPR property. Then one can always just re-run the whole'
works again from scratch.'
(3) Use a simple recursive descent control structure. The worst part about old'
TRANSOR was trying to use the editor for this. An absurd decision.'
But separate (a) the transformation to be applied from (b) the control of'
the recursion over the subforms of the (translated) expression. The point is '
that one often wants to run a small set of transformations, but you then need'
the recursion control for all the known functions to guide the sweep.'
(4) The user is unfamiliar with one of the two dialects involved, often with'
both. He will get done much quicker, even if he has to type  a lot more, if you'
do not use sophisticated features to "help" him. Thus': PRESCAN is a good notion'
but coding it in assemble was silly. Using the editor for expresssing the'
transormation of old forms to new is clearly wrong. The choice is between '
writing (SW 2 3) and writing'
The latter is clearly preferable! Because everyone knows what LAMBDA and  CAR'
do. Not everyone knows what SW will do. You think you know? What does it do,'
when embedded inside (LPQ (ORR (1) (NX)(!NX)) (COMS (GETP (CAR (##))''TRANSOFORMATION]  when the form that is supposed to have its second and third argument'
switched happens to have defaulted the third one? '
(5) Provide functions for things like (a) This form is an ordinary EXPR, go'
translate all its arguments recursively. (b) Translate just this subexpression'
recursively. (c) Give me the form enclosing this one, and a tail of it, of which'
this form is the CAR. (Like !0 and UP respectively). '
A suitable set of such functions, plus some conventions about where the rules'
or functions for translating subforms are stored, will be more useful and'
helpful than any more "fully automated" solution can be.'
If anyone does write such a package, I will be eternally relieved if he should'
call it TRANSOR. '
Jim Goodwin'
Received': from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 25 MAR 84 10':22':01 PST'
Return-path': <@SUMEX-AIM.ARPA':SHEBS@UTAH-20.ARPA>'
Redistributed': Xerox1100UsersGroup↑.PA'
Received': from UTAH-20.ARPA by SUMEX-AIM.ARPA with TCP; Sun 25 Mar 84 09':58':56-PST'
Date': Sun, 25 Mar 84 10':58':47 MST'
From': Stan Shebs <SHEBS@UTAH-20.ARPA>'
Subject': Re': Transor'
cc': 1100users@SUMEX-AIM.ARPA'
In-Reply-To': Message from "LINKOPING@BBNG.ARPA" of Sun 25 Mar 84 06':46':44-MST'
Why not use some version of Finin''s franzlator to build a TRANSOR?'
It has good syntax for writing patterns, does at least a marginal job'
on fexprs and macros, and does not use an editor.  It *was* designed to'
be used steadily rather than for a one-shot translation, so it meets'
that particular criterion.  It''s also pretty complete, so it could be'
used to translate itself to Interlisp, once the appropriate rules were'
written.  I''m working on rules to convert Franz <-> PSL, and hope to'
have a PSL version of franzlator eventually (pslator?)'
							stan shebs'
Received': from SUMEX-AIM.ARPA by PARC-MAXC.ARPA; 25 MAR 84 16':02':57 PST'
Redistributed': Xerox1100UsersGroup↑.PA'
Received': from USC-ISIB.ARPA by SUMEX-AIM.ARPA with TCP; Sun 25 Mar 84 15':12':07-PST'
Date': 25 Mar 84 15':10':05 PST'
Subject': Transor etc.'
From': Dave Dyer <DDYER@USC-ISIB.ARPA>'
To': 1100users@SUMEX-AIM.ARPA'
  I don''t believe there is such a thing as a translator between lisps.'
It is possible to translate gross forms to their rough equivalents, but'
below that level there are myriads of incidental features of one dialect'
that are difficult to anticipate or support in the intended host enviroment.'
  A tool such as transor is adequate to do 80% or so of the work, but'
looking for better, or trying to improve a translator to get to 100%'
is unrewarding.'
  The alternative to translating to common lisp is to implement'
the basis of Interlisp in common lisp, and then run your Interlisp'
programs untranslated.   This is the approach I used in the lisp machine'
Intelisp compatability package, and even more rigorously in the'
implemtation of Interlisp for the vax.'
  The performance penalty for using this approach is small, and probably'
negative compared to a program translated without a significant tuning effort.'
The additional advantage of this approach is that it keeps your programs'
in mostly their original form, so they can still be run in real Interlisp'
Date': 27 Mar 84 22':02 PST'
subject': Transor'
In-reply-to': LINKOPING@BBNG.ARPA''s message of Sun, 25 Mar 84 08':12':23 EST'
To': Linkoping@bbng'
cc': LispCore↑, 1100Support, Xerox1100UsersGroup↑.pa'
I had originally lobbied that Transor should be withdrawn as being "hopelessly obsolete"  as you mentioned. However, a number of people requested it, and some of them reported back that they had found it quite useful (although they had avoided prescan.)'
Thus, TRANSOR is still distributed (without any particularly useful transor-forms), although the appropriate caveats are usually not listed.'
One of the pitfalls of translation is that doing a "correct" job usually involves more proof techniques than the ordinary programmer has at his disposal. For example, in order to accurately change the order of arguments, you need to guarantee that the computation doesn''t depend upon the order of evaluation; if it does, you have to go to more lengths to translate. '
Secondly, the "langauge" of Lisp is quite small; what differentiates one Lisp from another is not the language (COND, SELECTQ, LAMBDA) but the "library" (window, linear programming, history, etc.), where some library packages tend to be either machine dependent or proprietary.'
In any case, as Dave Dyer suggests, emulation tends to work better than translation (sometimes emulation means hiding the transformations underneath macros and letting the compiler do the optimization phase). '
Received': from RUTGERS.ARPA by Xerox.ARPA ; 24 SEP 84 16':41':15 PDT'
Date': 24 Sep 84 19':41':00 EDT'
From': Jeffrey Shulman <SHULMAN@RUTGERS.ARPA>'
Subject': Common Lisp'
cc': 1100support.PA, SHULMAN@RUTGERS.ARPA'
	What''s the story regarding Xerox support of Common Lisp?  Due to'
our Arpa funding, we have been advised to discontinue purchasing Interlisp'
machines and buy from those vendors that will be supporting CL.'
	I personally feel that of all the Lisp Machines available, Interlisp-D'
has the best development environment.  I would hate to have to switch but'
my hands are tied unless Xerox will have CL support in the future.'


Test Case: 

Edit-By: Sannella.PA

Edit-Date: 25-Sep-84 12':36':43