Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP (Stanley Shebs)
Newsgroups: comp.sys.atari.st
Subject: Re: LISP for the ST
Message-ID: <4359@utah-cs.UUCP>
Date: Fri, 6-Mar-87 11:55:02 EST
Article-I.D.: utah-cs.4359
Posted: Fri Mar  6 11:55:02 1987
Date-Received: Sun, 8-Mar-87 06:17:24 EST
References: <8703060629.AA10665@ucbvax.Berkeley.EDU>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Distribution: world
Organization: PASS Research Group
Lines: 42

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