Copy Link
Add to Bookmark
Report
AIList Digest Volume 1 Issue 045
AIList Digest Monday, 22 Aug 1983 Volume 1 : Issue 45
Today's Topics:
Language Translation - Lisp-to-Lisp,
Programming Languages - Lisps on 68000s and SUNs
----------------------------------------------------------------------
Date: 19 Aug 1983 2113-PDT
From: VANBUER@USC-ECL
Subject: Lisp Interchange Standard
In response to your message sent Friday, August 19, 1983 5:26PM
On Lisp translation via a standard form:
I have used Interlisp Transor a fair amount both into and out of
Interlisp (even experimented with translation to C), and the kind of
thing which makes it very difficult, especially if you want to retain
some efficiency, are subtle differences in what seem to be fairly
standard functions: e.g. in Interlisp (DREMOVE (CAR X) X) will be EQ
to X (though not EQUAL or course) except in the case the result is
NIL; both CAR and CDR of the lead cell are RPLACed so that all
references to the value of X also see the DREMOVE as a side effect.
In Franz Lisp, the DREMOVE would have the value (CDR X) in most cases,
but no RPLACing is done. In most cases this isn't a problem, but ....
In APL, at least the majority of the language has the same semantics
in all implementations.
Darrel J. Van Buer, SDC
------------------------------
Date: 20 Aug 1983 1226-PDT
From: FC01@USC-ECL
Subject: Re: Language Translation
I like the APL person's [Shrager's] point of view on translation.
The problem seems to be that APL has all the things it needs in its
primative functions. Lisp implementers have seen fit to impurify
their language by adding so much fancy stuff that they depend on so
heavily. If every lisp program were translated into lisp 1.5 (or
so), it would be easy to port things, but it would end in
innefficient implementations. I like APL, in fact, I like it so much
I've begun maintaining it on our unix system. I've fixed several
bugs, and it now seems to work very well. It has everything any
other APL has, but nobody seems to want to use it except me. I write
simulators in a day, adaptive networks in a week, and analyze
matrices in seconds. So at any rate, anyone who is interested in APL
on the VAX - especially for machine intelligence applications please
get in touch with me. It's not ludicrous by the way, IBM does more
internal R+D in APL than in any other language! That includes their
robotics programs where they do lots of ARM solutions (matrix
manipulation being built into APL has tremendous advantages in this
domain).
FLAME ON!
[I believe this refers the Stan the Leprechaun's submission in
V1 #43. -- KIL]
So if your language translation program is the last word in
translators, how come it's not in the journals? How come nobody knows
that it solves all the problems of translation? How come you haven't
made a lot of money selling COBOL to PASCAL to C to APL to LISP to
ASSEMBLER to BASIC to ... translators in the open market? Is it that
it only works for limited cases? Is it that it only deals with
'natural' languages? Is it really as good as you think, or do you only
think it's really good? How about sharing your (hopefully non
NPcomplete) solution to an NP complete problem with the rest of us!
FLAME OFF!
[...]
Fred
------------------------------
Date: Sat 20 Aug 83 15:18:13-PDT
From: Mabry Tyson <Tyson@SRI-AI.ARPA>
Subject: Lisp-to-Lisp translation
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.
------------------------------
Date: 19 Aug 83 10:52:11-PDT (Fri)
From: harpo!eagle!allegra!jdd @ Ucb-Vax
Subject: Lisps on 68000's
Article-I.D.: allegra.1760
A while ago I posted a query about Lisps on 68000's. I got
essentially zero replies, so let me post what I know and see whether
anyone can add to it.
First, Franz Lisp is being ported from the VAX to 68000's. However,
the ratio of random rumors to solid facts concerning this undertaking
seems the greatest since the imminent availability of NIL. Moreover,
I don't really like Franz; it has too many seams showing (I've had too
many programs die without warning from segmentation errors and the
like).
Then there's T. T sounds good, but the people who are saying it's
great are the same ones trying to sell it to me for several thousand
dollars, so I'd like to get some more disinterested opinions first.
The only person I've talked to said it was awful, but he admits he
used an early version.
I have no special knowledge of PSL, particularly of the user
environment or of how useful or standard its dialect looks, nor of the
status of its 68000 version.
As for an eventual Common Lisp on a 68000, well, who knows?
There are also numerous toy systems floating around, but none I would
consider for serious work.
Well, that's about everything I know; can any correct me or add to the
list?
Cheers,
John ("Don't Wanna Program in C") DeTreville
Bell Labs, Murray Hill
[I will reprint some of the recent Info-Grpahics discussion of SUNs
and other workstations as LISP-based graphics servers. Several of
the comments relate to John's query. -- KIL]
------------------------------
Date: Fri, 5 Aug 83 21:30:22 PDT
From: fateman%ucbkim@Berkeley (Richard Fateman)
Subject: SUNs, 3600s, and Lisp
[Reprinted from the Info-Graphics discussion list.]
[...]
In answer to Fred's original query, (I replied to him personally
earlier ), Franz has been running on a SUN since January, 1983. We
find it runs Lisp faster than a VAX 750, and with expected performance
improvements, may be close to a VAX 780. (= about 2.5 to 4 times
slower than a KL-10). This makes it almost irrelevant using Franz on
a VAX. Yet more specifically in answer to FRD's question, Franz on
the SUN has full access to the graphics software on it, and one could
set up inter-process communication between a Franz on a VAX and
something else (e.g. Franz) on a SUN. A system for shipping smalltalk
pictures to SUNs runs at UCB.
Franz runs on other 68000 UNIX workstations, including Pixel, Dual,
and Apple Lisa. Both Interlisp-D and MIT LispMachine Lisp have more
highly developed graphics stuff at the moment.
As far as other lisps, I would expect PSL and T, which run on Apollo
Domain 68000 systems, to be portable towards the SUN, and I would not
be surprised if other systems turn up. For the moment though, Franz
seems to be alone. Most programs run on the SUN without change (e.g.
Macsyma).
------------------------------
Date: Sat 6 Aug 83 13:39:13-PDT
From: Bill Nowicki <NOWICKI@SU-SCORE.ARPA>
Subject: Re: LISP & SUNs ...
[Reprinted from the Info-Graphics discussion list.]
You can certainly run Franz under Unix from SMI, but it is SLOW. Most
Lisps are still memory hogs, so as was pointed out, you need a
$100,000 Lisp machine to get decent response.
If $100,000 is too much for you to spend on each programmer, you might
want to look at what we are doing on the fourth floor here at
Stanford. We are running a small real-time kernel in a cheap, quiet,
diskless SUN, which talks over the network to various servers. Bill
Yeager of Sumex has written a package which runs under interLisp and
talks to our Virtual Graphics Terminal Service. InterLisp can be run
on VAX/Unix or VAX/VMS systems, TOPS-20, or Xerox D machines. The
cost/performance ratio is very good, since each workstation only needs
256K of memory, frame buffer, CPU, and Ethernet interface, while the
DECSystem-20 or VAX has 8M bytes and incredibly fast system
performance (albeit shared between 20 users).
We are also considering both PSL and T since they already have 68000
compilers. I don't know how this discussion got on Info-Graphics.
-- Bill
------------------------------
Date: 6 Aug 1983 1936-MDT
From: JW-Peterson@UTAH-20 (John W. Peterson)
Subject: Lisp Machines
[Reprinted from the Info-Graphics discussion list.]
Folks who don't have >$60K to spend on a Lisp Machine may want to
consider Utah's Portable Standard Lisp (PSL) running on the Apollo
workstation. Apollo PSL has been distributed for several months now.
PSL is a full Lisp implementation, complete with a 68000 Lisp
compiler. The standard distribution also comes with a wide range of
utilities.
PSL has been in use at Utah for almost a year now and is supporting
applications in computer algebra (the Reduce system from Rand), VLSI
design and Computer aided geometric design.
In addition, the Apollo implementation of PSL comes with a large and
easily extensible system interface package. This provides easy,
interactive access to the resident Apollo window package, graphics
library, process communication system and other operating system
services.
If you have any questions about the system, feel free to contact me
via
JW-PETERSON@UTAH-20 (arpa) or
...!harpo!utah-cs!jwp (uucp)
jw
------------------------------
Date: Sun, 7 Aug 83 12:08:08 CDT
From: Mike.Caplinger <mike.rice@Rand-Relay>
Subject: SUNs
[Reprinted from the Inof-Graphics discussion list.]
[...]
Lisp is available from UCB (ftp from ucb-vax) for the SUN and many
simialr 68K-based machines. We have it up on our SMI SUNs running
4.1c UNIX. It seems about as good as Franz on the VAX, which from a
graphics standpoint, is saying nothing at all.
By the way, the SUN graphics library, SUNCore, seems to be an OK
implementation of the SIG Core standard. It has some omissions and
extensions, like every implementation. I haven't used it extensively
yet, and it has some problems, but it should get some good graphics
programs going fairly rapidly. I haven't yet seen a good graphics
demo for the SUN. I hope this isn't indicative of what you can
actually do with one.
By the way, "Sun Workstation" is a registered trademark of Sun
Microsystems, Inc. You may be able to get a "SUN-like" system
elsewhere. I'm not an employee of Sun, I just have to deal with them
a lot...
------------------------------
End of AIList Digest
********************
