rich@eday.pilchuck.Data-IO.COM (Rich Wallick) (10/03/88)
hi Here's an edited version of the responses to a which LISP should I... Thanks to all of you who took the time to respond! All opinions below are someone elses, as I've been paying too much attention to the presidential race to have any of my own. 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. KCL is practically unusable for operations on large arrays. Even compiled code costs too much on such operations, and GC's itself to death. 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. The chief benefit from compiling KCl into C is that KCl is then more portable. A 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. 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. KCl is not unreasonable for development, though its debugger needs work; there's not always enough information available. Lucid, on a SUN, can use the 68881 math coprocessor, but not the FPA board. I use Lucid's foreign function extensions for calling C routines to improve performance and use the FPA. They C callout works well, although the allowed data types are rather restrictive. Sun distributes Lucid common lisp; I have been using it and it's pretty good; has a good foreign function interface which I think 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. If the utah lisp (from the university) same one that HP used to distribute (they have now switched to Lucid) and I think it may be, than I warn you away from it. It has almost no provisions for foreign function calls, etc...