Path: utzoo!attcan!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Looking for KCL on MIPS & AKCL.
Message-ID: <3696@skye.ed.ac.uk>
Date: 5 Nov 90 17:22:45 GMT
References: <3685@skye.ed.ac.uk> <1990Nov2.094418.9391@ulrik.uio.no>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 70

In article <1990Nov2.094418.9391@ulrik.uio.no> espen@math.uio.no (Espen J. Vestre) writes:
>In article <3685@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>> Just because you can get the machine, one way or another, doesn't
>> mean you have enough money for commercial Lisp systems too.  [...]

>I can see your point.  But isn't it sometimes better to telnet to a 
>machine running a better lisp implementation?

Yes.  I do that too.  But not everyone has such other machines.

Indeed, the Dept. of AI in Edinburgh would probably not have been able
to use Common Lisp for teaching at all if it had not been for KCL.  We
had KCL back in 1985, before there was much in the way of other Common
Lisps; it was affordable; and it ran on (or could be ported to) the
machines we had.  Even now it would be too expensive to get a
commercial license for all the machines used by students.

(It is perhaps because we had KCL so early on that we have a more
positive view of Common Lisp than some other people/places in the
UK.)

>The reason I looked into AKCL was somewhat different - I wanted to make 
>sure that my MACL program was portable to other CLs.  

In my opinion, it's a good idea to try KCL when checking portability,
but it isn't enough on its own.  You would also have to try some of
the commercial CLs.

However, KCL used to be more misleading as a portability check than it
is now.  KCL used to have annoyingly nonstandard "evaluation times"
for top- level forms, which meant that EVAL-WHENs had to be added to
programs originally written in KCL; but that has been fixed in AKCL.

>I wasn't able to run it, however ("value stack overflow", could this
>be corrected by setting up AKCL in another way?).

You could try rebuilding KCL with a bigger stack.  It's also a good
idea to compile such code to see if that helps.

>Luckily, I discovered that I was able to "borrow" a NeXt by telnetting to 
>it (And NeXts come bundled with Allegro CL as you may know).

Is that Allegro as in Franz Inc or Allegro as in Apple?

>> Sometimes.  But it's smaller than the commercial Common Lisps I've
>> tried.  So, on machines like an 8 meg SPARCstation, it can be much
>> easier to use, because it doesn't spend so much time paging.  For
>> large programs, though, this advantage may be lost.
>
>This reminds me of another question I have:  Why on earth are these 
>systems so large??

The main reason, I suspect, is that being small wasn't much of a
priority when they were written.  There must have been many cases
where they thought "should we make this smaller or faster?" and
chose faster.

They also tend to have more sophisticate compilers.  It is possible
to have a reasonably good compiler that is fairly small, but such
compilers will fall short of the best compilers in various ways
(by doing fewer optimizations, for example).

And then there are the built-in functions.  KCL implements the
sequence functions in a straightforward, but not very efficient,
way.  A commercial CL may make a much greater effort to handle
different sequence types in different ways.  Lists, simple-vectors,
strings, simple-strings, vectors, and strings might all be different
cases.

-- Jeff