Many Common Lisp implementations for Unix are modeled after the ``Lisp Machine'' view of computing. A Lisp development environment is often a multi-megabyte executable that contains a compiler, evaluator, dynamic linker, debugger, runtime library, threads package, editor, window system interface, etc., all running in a single address space. Support for passing data to foreign languages is typically quite good, although great effort is usually taken to distinguish Lisp data from foreign data. However, because Lisp programs cannot be provided to other programmers in a form compatible with the native system linker, Lisp must remain ``in control'' by linking foreign code into the Lisp image. Unfortunately, foreign debugging information is usually lost in the process, thus making debugging of mixed language programs difficult.
Standalone applications are produced by dynamically loading application code into a running Lisp and then saving a memory image to disk. Autoloading can be used to delay the loading of code until runtime, thus reducing image size, but it can substantially increase the startup time of an application. Treeshakers and selective loading of subparts of the Lisp system are also used to reduce the size of saved memory images, but the inherently intertwined nature of Common Lisp makes this difficult to use effectively. Furthermore, the read-only portions of a memory image can be shared only with other people running exactly the same image. Thus, every application that is even partially written in Lisp must duplicate both on disk and in memory a significant portion of the Lisp runtime library, no matter how small the executable size becomes.