steve@presto.ig.com (Steve Barnhouse) (08/30/88)
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
jeff@aiva.ed.ac.uk (Jeff Dalton) (09/06/88)
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
jbn@glacier.STANFORD.EDU (John B. Nagle) (09/14/88)
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