An extensive Scheme-only bibliography is posted to comp.lang.scheme.
[I forgot to cross-post to this newsgroup.] I have been maintaining
this bibliography [in bib/refer format], and will post updates from
time to time. Any additions and/or corrections would be much
appreciated.
oz
--
Crud that is not paged | Usenet: ...!utzoo!yunexus!oz
is still crud. | ...uunet!mnetor!yunexus!oz
······@alice | Bitnet: ··@[yulibra|yuyetti]
| Phonet: +1 416 736-5257x3976
From: Steve Barnhouse
Subject: Kyoto Common Lisp info wanted
Date:
Message-ID: <6772@ig.ig.com>
I'm interested in finding out about Kyoto Common Lisp. I've
heard that it is very compact and that it can compile into C,
both of which sound advantageous for production software. How
about development?
In general, is Lisp just a development language, or can it be
taken seriously as a language for production and marketing too?
If you have any real experience with Kyoto Common Lisp, I'd like
to hear about it. If you have marketed an application in Lisp,
I'd like to hear about that too.
Thanks,
--Steve
From: Jeff Dalton
Subject: Re: Kyoto Common Lisp info wanted
Date:
Message-ID: <573@aiva.ed.ac.uk>
In article <····@ig.ig.com> ·····@presto.ig.com (Steve Barnhouse) writes:
>I'm interested in finding out about Kyoto Common Lisp. I've
>heard that it is very compact and that it can compile into C,
>both of which sound advantageous for production software.
KCl is smaller than many Common Lisps. Whether KCl compiled code is
particularly compact is unclear. It would, in any case, depend on the
C compiler. KCl's data structures are somewhat larger than they need
be. For example, a cons cell is larger than two pointers because it
has some GC and type information tacked onto the front.
The chief benefit from compiling KCl into C is that KCl is then more
portable; it does not necessarily result in more C-like compiled code.
This is because compilation into C is not the same as translating into
C -- or, rather, it is a fairly low-level, literal translation. Still,
proper use of declarations can get results similar to writing directly
in C (though it still won't look as nice) -- in some cases. Other
Common Lisps, that don't compile via C, can of course generate the
same (or better) code.
A remaining possible advantage to the KCl approach might be that it
gave better support to mixed Lisp and C. However, other Common Lisps
tend to do a fairly good job of that these days and are often more
convenient than KCl in many cases.
For more information about KCl, and in particular William Shelter's
version, AKCl, see AI Expert, v3n3, March 1988. AKCl is somewhat
more C-like in that it makes more use of the C stack for passing
arguments and storing local variables. [Standard KCL uses a separate
stack for Lisp objects, which may make the calling sequence slower.]
>How about development?
KCl is not unreasonable for development, though its debugger needs
work (there's not always enough information available, and it's often
not very readable, especailly for compiled code). KCl's tracer is
rather minimal, but better ones can be added. [In the US at least,
you can get the Spice Lisp trace and add it to KCl with only minor
modifications.]
>In general, is Lisp just a development language, or can it be
>taken seriously as a language for production and marketing too?
I'm not sure what it means to be a language for marketing.
As for production, Lisp can be large and slow, and it tends to
expect you to live in the Lisp world rather than in Unix or whatever.
However, Lisp implementors are aware of these problems, and Lisp
systems are getting better. There is nothing about the language
(as opposed to implementations) that should prevent it from being
taken seriously.
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
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