Conference hydra::amiga_v1

	I called these folks today and got some more info:

	- The Common Lisp subset consists of about 150 of "the most
	heavily used functions"...

	- He didn't have any benchmark numbers available.

	- There's a special variable that will let you bind your favorite
	text editor into the Lisp interpreter.

	- It currently does NOT have any hooks into Amiga-specific features,
	however, there is an upgrade due out in January that will have those
	capabilities.

	- THEY ARE ALMOST READY WITH A COMMON LISP COMPILER FOR THE AMIGA !!
	(Supposedly available sometime in the January time-frame)
	
	- Their secret identity is:



		McCauley Software Systems
		P.O. Box 271031
		Houston, TX  77277-1031
		(713)630-0647

	- They only take checks, money orders, and COD's, no credit cards.

	I'll post a review when mine gets here...

	To begin with, I think calling this thing an implementation of
	Common LISP is pushing it a bit.  The author has taken many liberties
	with the language definition specified in Steele's "Common LISP the
	Language" (CLtL).
	
	In addition, the implementation suffers from various limitations and
	inconsistencies that make it useless for anything but the most
	elementary purposes.  For example:

	1) (DEFUN ...) doesn't support the use of &KEY, &OPTIONAL, or
	&REST.

	2) (DEFVAR ...) is not part of the language; indeed, special variables
	of any kind seem to be missing altogether.  This lack of special
	variables also extends to the complete absence of any of the system
	variables defined in CLtL.

	3) (DEFSTRUCT...) isn't supported; neither are HASH-TABLEs.  
	Irritatingly, McCauley's LISP doesn't even have a (GENSYM...) 
	capability.

	4) The READer is extremely limited: no read-macro characters , in fact
	no notion of access to the READ-TABLE at all.

	5) CAR and CDR are defined, but CxxxxxR compositions (CADR, CADDR, etc)
	have to be hand-defined as macro's; they're not there automatically.

	6) The syntax of various functions is funny sometimes.  For example,
	the (LOAD...) command ONLY accepts things of the form (LOAD 'filename),
	not (LOAD "filename") as it is described in CLtL.  Even within itself,
	this interpreter is inconsistent, however, because while LOAD takes
	(LOAD 'file), the call to the editor looks like: (ED "filename") !!

	7) Error recovery seems flakey: a stack overflow is supposed to give
	a message and then exit; instead, it gives the message, begins dumping
	TONS of garbage to the screen (I suspect it's a dump of the whole stack 
	or something -- that isn't documented anywhere), and then it exits.
	With a stack on the order of 50K bytes, it's easier to reboot than
	wait for it.

	8) It should come as no surprize that there is no interface with any
	Amiga system routines.

	9) And finally there's the documentation.  It covers all the functions
	adequately, but there's no index; since some of the functions are
	described in the reference section and others in the tutorial, it is
	difficult to find things at times.  Also, I spent a lot of time looking
	for a list of the special system variables used by this implementation,
	until I realized that there aren't any !

	All in all, I think this is a pretty useless piece of software; it looks
	more like someone's senior-year project than a commercial product.  
	They're charging $70 for it; it might be worth $25 if you knew nothing
	about LISP and you just wanted a toy interpreter to get started with.
	On the other hand, XLISP is available in public domain and it DOES 
	have many of the features of a real LISP implementation.

	So, fellow LISPers, our favorite computer is still without any kind
	of decent LISP software.  Oh well, maybe next year...

	Art Baker

Well Art,
your description about the origin of the product sounds accurate.
Probably by a _failing_ student at that.

Rats.
My amiga still collects dust, waiting for a Common Lisp.

Dave

    Rather than letting your Amiga collect dust, implement Common Lisp
    yourself!  The kernel is just CAR, CDR and CONS: you can code them
    in C.  Add READ, GENSYM, RPLACA, RPLACD, ATOMP, PUTPROP, GET and
    probably a couple of others that I've forgotten, and you've got
    enough to write EVAL in LISP.  From that point you can define the
    rest of Common Lisp in (subset) Lisp from the book.  It might run
    a little slow, but it will give you a nice clean implementation.
    
    Later you can convert some of the Lisp parts to C, if you want better
    performance.
    
    Just a Small Matter of Programming.
        John Sauter

	re: .-1

	Not to dampen your enthusiasm, John, but there's a LOT more to
	a LISP implementation than just a couple of CARs, CDRs, and a
	PUTPROP-in-a-pear-tree.   What Dave and I are looking for is a
	real honest-to-god Common LISP compiler.  One that provides
	enough functionality to allow the development of REAL software.  

	Purely interpretd LISPs (ala XLISP) simply don't have the speed
	necessary to support more than the writing of toy programs.  Sad
	but true.  And if large parts of the interpreter are themselves
	just LISP macros -- forget it !  Do (REVERSE '(a b c)) and go
	out for lunch....

	This is especially sad, because excellent LISPs are available for
	machines from the "Typewriter Company" and the "Fruit Vendor".
	TI is even marketing (or will be) a LISP-chip board for the MAC II !
	Oh well....

	Art Baker			| "People who say that money can't
					|  buy everything just don't know
					|  where to shop..."
					| - Mrs Thurston Howell  III

    Gee, I worked with a fully-interpreted system, and managed to produce
    some school-level software.  I admit that the sort of software written
    as school projects isn't "real" software, but it isn't so far distant
    that I would dismiss interpreters as impossibly slow.
    
    On the other hand, I last used Lisp in 1968; perhaps expectations
    of program size and complexity have increased since then.
    
    Well, OK, if you need a compiler, write one of those too.  To make
    things easy, make your compiler emit C, then compile the C.  Should
    be a piece of cake.
        John Sauter

	re: .6

>    On the other hand, I last used Lisp in 1968; perhaps expectations
>    of program size and complexity have increased since then.

	I suspect they have, John.  Also, one of usual strategies these
	days is write domain-specific languages in LISP to deal with
	particular kinds of problems -- kind of a language-within-a-
	language.  A double interpreter would die...
    
>    Well, OK, if you need a compiler, write one of those too.  To make
>    things easy, make your compiler emit C, then compile the C.  Should
>    be a piece of cake.

	Here too, things get weird.  One of the great beauties of LISP is
	that one can generate a function as part of the working of the
	program, and then invoke the (COMPILE ...) function to compile
	it -- in essence a program generating itself on the fly.  Not so
	nice if you need to call Lattice or Manx in another process.

	'(Art)

    Golly, AmigaDOS has multitasking.  Surely you can make the COMPILE
    routine write the appropriate file and initiate a process that invokes
    the compiler, and when it's done read in the object file.  You might
    need a lot of memory, but hay, Lisp systems have always needed lots
    of memory.
        John Sauter

Supporting Common Lisp, ala Common Lisp, the Language,
(Steele, Digital Press)
is more work than you can possibly imagine, even taking those
portions of bootstrapped lisp implementation which are public domain.
The best bet, were I willing to try, and not for personal profit,
would be to port KCL (Kyoto Common Lisp) to the Amiga.

Paul Wisner was going to attempt this, but I haven't heard much
about success with it. (I'm still anxiously awaiting your shouts of
success Paul!).

I did consider doing one myself, but basically decided that
I would only attempt it if there was commercial gain as a target,
and that would definitely constitute conflict of interest (and competition)
with DEC.  

A compiler is DEFINITELY a must.  Vax Lisp, a highly tuned common lisp
for the VAX architecture, turns my microvax into a toy with any sizeable
lisp applications (mostly during development/debugging, generally resulting 
applications can run quite nicely on a microvax).  In order for reasonable
development and environment on an Amiga, an integrated, highly optimizing
compiler is a must.  This is a lot of work for Lisp, more so than
many traditional compilers, such as C.  The reason is the consideration
necessary in order to efficiently perform tagged operations on an untagged
architecture.

This is why many Common Lisp implementations for Mac's, IBMPc's
and other machines generally cost upwards of $800. 

Xlisp is a toy. Terrific if you are just trying to learn a little about
lisp.  I want to do some serious graphics and application development,
and this requires a serious lisp.  So I'm just patiently waiting for
a good Common Lisp for the Amiga. Of course, by the time one materializes,
I'll probably have finagled someone into buying me a machine with a few
more mips and won't use the amiga because I've become spoiled...

After writing DECWEB (see Z::DECWEB conference for details),
I've been hankering to write a much better, for profit, game doing the
development on my Amiga.  My requrements for development
would be Common Lisp with a good implementation of CLOS (the common lisp
object system).  This because the new game has very heavy need of an
object oriented programming system with multiple inheritance; and
C++ (aside from being single inheritance), isn't my bag.
Adding CLOS to a full Common Lisp is even more work (but very little,
depends on how much additional efficiency you want); but has a lot
of execution overhead.  Again, you'll need a good lisp/compiler
if you want a prayer of running CLOS on a 68000.  

One thing XLISP would be good at, given a suitable Intuition interface,
would be doing graphics from lisp.  You haven't lived until you've
done graphics from lisp.  Art and I once considered this long ago
(remember Art?); but there was just never enough motivation I guess.
So now I'm reduced to a begging end-user, who only writes enough notes
in this conference to try to keep the desire/quest for a good Amiga lisp
alive.