[comp.sys.atari.st] Lisp for the ST

FORSTER@cs.umass.edu (David Forster) (03/05/87)

I'm looking for a decent version of LISP for the ST, but there doesn't seem to
be much out there.  I've only heard of Cambridge LISP, XLISP, and something
from Robinson Systems in the U.K.
  The version of XLISP which I have is too slow and buggy for my purposes,
but it's about a year out of date and I expect that XLISP has improved in the
mean time.  I'd fix the bugs I run into in this version, but I don't have a
C compiler, and have no intention of buying one just for this.  In any event,
there's still the problem of speed.
  The Robinson Systems LISP is simply inadequate, according to the material
they sent me.  It appears to have smaller coverage than does XLISP, and they
still want something like $150 for it.  It's supposed to be based on Common
LISP, but lacks such things as setf, defstruct, and even defmacro.
  All I have seen of Cambridge LISP is advertising by Metacomco, and a review
in AI Expert Magazine.  According to the review, there are some problems with
the product: it uses dynamic scoping when interpreted, but lexical scoping
when compiled; it seems to be slow*; it's not Common LISP, but Portable
Standard LISP; it doesn't have defstruct's, but it does have arrays**; as I
recall, it's a nuisance to compile functions, but I don't recall why.
On the plus side, it does have a compiler, it has VDI functions and such
defined, and it's possible to save images, meaning that binary code can be
distributed without problems.
* - Benchmarks showed that it ran 20 times slower than equivalent products on
    the Mac, BUT the Cambridge LISP was being interpreted, and the Mac stuff
    was running compiled.  If the Cambridge code had been compiled, it would
    probably have performed better, but 20 times better?  I don't think so.
**- Why on earth they didn't go that extra step to define structures I do not
    know.  Surely it's not that much work?  It should be possible to define
    structs based on arrays without very much work (and/or based on lists, but
    access to arrays will be faster).

Does anyone out there have information about other LISP's?  Does anyone have
a copy of Cambridge LISP which they'd like to report on?  I must admit that
I'll be finicky about the LISP I buy, since I'm used to working on LISP
machines like the TI Explorer and Symbolics 3600-series machines.  I don't
expect an ST LISP to match that level of performance, but I do expect it to
have most of the power of Common LISP and fairly similar syntax, and not make
me wait too much.  It ought to have a package system, structures, and that sort
of stuff, but there are work-arounds for those.  It needn't be cheap, but I
want good value for my money.

Sorry if this has been discussed before, but our site missed two months of
digests for some reason.  (If it has been discussed before, can someone please
mail me what they have on it?)

Thanks, David Forster

CSnet:   forster@umass-cs.csnet
ARPAnet: forster@umass-cs.csnet%csnet-relay.arpa
BITnet:  forster@umass
USENET:  your guess is as good as mine :-)

shebs@utah-cs.UUCP (Stanley Shebs) (03/06/87)

In article <8703060629.AA10665@ucbvax.Berkeley.EDU> FORSTER@cs.umass.edu (David Forster) writes:

>Benchmarks showed that it [Cambridge Lisp] ran 20 times slower than
>equivalent products on the Mac, BUT the Cambridge LISP was being interpreted,
>and the Mac stuff was running compiled.  If the Cambridge code had been
>compiled, it would probably have performed better, but 20 times better?
>I don't think so.

Actually, that's a common rule of thumb for compiled vs interpreted Lisps,
though the number varies from 10 times faster to maybe 100 times faster
for compilation. Depends on smartness of compiler and smartness of
interpreter, and also on the dialect...

>Why on earth they didn't go that extra step to define structures I do not
>know.  Surely it's not that much work?  It should be possible to define
>structs based on arrays without very much work (and/or based on lists, but
>access to arrays will be faster).

Defstructs based on some other object (say arrays) are easy to do, just a
hairy macro.  Charniak/Riesbeck/McDermott's AI Programming Techniques
(published by Lawrence Erlbaum Associates) discusses the details of writing
one.  A fly in the ointment tho - no way to distinguish an array created
via defstruct from one created by make-array.  So serious Lisps have an
additional datatype that is like an array but is not arrayp.  The people
that built Cambridge Lisp care a little about semantics, so I imagine they
rejected the easy but unsafe way to do defstructs, and didn't want the
overhead associated with a completely new datatype either.

>Does anyone out there have information about other LISP's?

Sandra Loosemore has been working on a full-scale CL for the ST, but
she's been slacking off lately.  The compiler is reasonably good...

Also, we've been putting together a PSL successor at Utah designed to be
efficient, portable, modular, etc.  It prints out "hello world" now, but
not much more!  Anyway, since I've just acquired an ST, a port to it will
no doubt happen in the near future (we already have 68K code generation)...

>Thanks, David Forster

							stan shebs
							shebs@cs.utah.edu

JALKIO@cc.helsinki.fi (Jouni Alkio, University of Helsinki, Finland) (11/25/89)

I would like to get information about Lisp compilers/interpreters for
the Atari ST. I have only seen the Cambridge Lisp from Metacomco.
Please, tell me if you know something.

				Jouni Alkio

roland@tuvie (Inst.f.Allg.Elektrotechnik) (11/25/89)

PD sources in Germany have XLISP 2.0 for the Atari ST.
This is an interpreter written in C by David Michael Betz,
127 Taylor Road, Peterborough, NH 03458.
It features object-oriented extensions and comes with 49 pages
of documentation. It is available in source form to non-commercial
users.

Roland Schreier         _                     Technical University of Vienna
Gusshausstrasse 27-29  |_)  _  |  _   _   _|  +43 (222) 58801 3838
A-1040 Wien            | \ (_) | (_| | | (_|  SCHREIER@EAECL1.UNA.AT
Oesterreich - Europe                          roland@tuvie.at