The idea of using standard operating system delivery mechanisms is represented by such systems as Wade Common Lisp (WCL), produced by Wade Hennessey at Standford University in 1992. This capitalized on Sun's shared-object library technology to create small-executable Lisp applications.[Hennessey] Conscious Computing has produced LinkLisp, which features a specialized Lisp compiler implemented as a Windows DLL and VBX.
Meanwhile, Bruno Haible of Karlsruhe University and Michael Stoll of Munich University produced CLISP. This is a widely used extended CLtL1 Lisp that uses portable C to implement a Lisp byte-code engine.[Haible]
The leading commercial Lisp-to-C translator through the 1980s was the Chestnut system. This $12,000 system translated complete applications into C from within other commercial Lisp systems. The result was linked with a library to run. The rights to this system have been sold to a major database and business software vendor that uses it internally but does not make the system available to others. Wolfgang Goerigk, Ulrich Hoffmann, and Heinz Knutzen of the University of Kiel are now working on CLiCC, which translates a carefully defined static subset of Common Lisp.[Hoffmann] CLiCC retains the ``separate Lisp data stack'' architecture used in the classical ``C as assembly language'' designs.
A number of similar systems exist for Scheme and other Lisp dialects, notably Scheme->C, Stalin, and ILOG Talk.
Eclipse is not directly based on any of these, but instead synthesizes
the major concepts of all. The principal advance is in the tight,
idiomatic integration of Lisp and C. The appearance of Lisp calls is
as ordinary C, the appearance of C calls is as ordinary Lisp, and Lisp
data is handled as ordinary C data. Eclipse is probably also the first
Lisp implementation designed from the start to conform to the ANSI
Common Lisp standard, and includes a native implementation of CLOS and
the CLOS-MOP.
5.2: Planned Work
Eclipse has been available commercially since September 26, 1997, and
is stable and complete.
The development strategy has followed the dictum ``first make it right,
then optimize.'' It is now time to optimize, and this is the bulk of
the current development activity. Preliminary results show that we
will be able to expect C-like performance for C-like Lisp code
compiled to C by COMPILE-FILE, and more generally, speed comparable to
other commercial Lisp systems for compiled-to-C applications.
The Eclipse compiler and interpreter are actually a generalized code walker that follows an ``Open Implementation'' or MOP-based protocol. This allows the walker to be specialized for different processing requirements. Walking with respect to an interpreter environment returns results directly, while walking with respect to a C-compiler environment returns pseudo-code that is pretty-printed to produce C source files. We expect that this technique, combined with Eclipse's MOP implementation, can be used to generate other compiled formats, including other source languages such as C++, or various forms of byte code such as Java Virtual Machine code. By extending the technique of special compilation for particular kinds of functions, we expect to be able to produce specialized code for statically determined methods, including idiomatic compilation of target language (i.e., Java) metaobjects. Because the Eclipse library was written in Lisp and self-compiled to C, rather than being written directly in C, new libraries can be generated for these new formats.
By tightly integrating Lisp and C, we also plan to capitalize on such current advances as dynamic loading of machine code and native threads. Eclipse already uses parts of PPCR, which makes these portably available to C programmers.[Demers]