Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!etive!aiva!jeff
From: jeff@aiva.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Kyoto Common Lisp info wanted
Keywords: development vs production
Message-ID: <573@aiva.ed.ac.uk>
Date: 5 Sep 88 19:55:30 GMT
References: <845@yunexus.UUCP> <6772@ig.ig.com>
Reply-To: jeff@uk.ac.ed.aiva (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Lines: 55

In article <6772@ig.ig.com> steve@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: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton