Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!labrea!glacier!jbn
From: jbn@glacier.STANFORD.EDU (John B. Nagle)
Newsgroups: comp.lang.lisp
Subject: Re: Kyoto Common Lisp info wanted
Keywords: development vs production
Message-ID: <17704@glacier.STANFORD.EDU>
Date: 14 Sep 88 02:41:38 GMT
References: <845@yunexus.UUCP> <6772@ig.ig.com> <573@aiva.ed.ac.uk>
Reply-To: jbn@glacier.UUCP (John B. Nagle)
Organization: Stanford University
Lines: 23


     KCL is a good system if what you want is Common Lisp as defined in
Steele's "Common Lisp, The Language".  It is an implementation of that
definition, and very little more.  If it isn't in CLTL, it isn't in KCL.
In particular, there is no attempt to provide an object-oriented programming
facility.

     The memory management is rather simple.  Garbage collection is a simple
mark/sweep algorithm.  However, since the compiler is a separate program,
running in an address space of its own, the garbage generated by the compiler
is seldom collected; the compiler finishes, exits, and the compiler process
dies.  KCL allocates one or more blocks of memory for each data size, then
allocates items of uniform size within each block.  Thus, fragmentation is
not a problem unless the number of different sized objects is very large.
All in all, the simple approach seems to work more than adequately.

     I've used both Lucid and KCL on the same Sun III.  As of summer 87,
the code seemed roughly comparable in performance.  KCL started faster
and was a much smaller system.  Lucid had vastly more features.  Both
ran the same large but vanilla Common Lisp program with almost no modifications.
KCL is much cheaper, being free.

					John Nagle