Common Lisp Implementations: A Survey

There has been a new wave of interest in Common Lisp over the last few
years. This paper is a November, 2007 (updated February, 2010) survey
of Common Lisp implementations that are currently being actively
maintained. It also provides references to writings about why Lisp is
interesting and important, Lisp textbooks, and useful Lisp resources
including repositories of available libraries. I hope it will help
you find the right implementation for your project or product.

This paper also contains pointers to useful Web pages related to Lisp
(including many dialects, not just Common Lisp). The organization is:

Implementations

How did I pick the implementations to include in the survey? Research
on the Internet showed that of all the implementations, some were
full-fledged in their time, but have been abandoned for one reason or
another, and some don't really count as being the Common Lisp dialect.

There are eleven real currently-maintained implementations. I judged
this by seeing which implementations were currently being supported by
prominent libraries and tools, by seeing whether there was active
mail/news/etc. traffic about the implementation, by searching the web
and asking around. Obviously this was something of a judgement call
on my part. If I omitted any, it was certainly not on purpose.
Please let me know if there are others.

I did not run the implementations. I did not do any benchmark
(performance) comparisons of runtime or compiler speed, and you'll
find little in this paper about performance. I did not attempt to
independently verify the answers to the survey. No organization
endorses this paper. In particular, the web site on which you found
this paper does not endorse it and bears no resposibility for its
contents. I feel very confident that everybody who responded to the
survey did so in good faith. Any errors are entirely my fault.
Please send corrections to me.

I have not attempted to determine how closely each implementation
adheres to the X3J13 specification. Sadly, there is no comprehensive
language compatibility test suite. Such suites are extremely
difficult, not to mention boring, to create.

This survey only covers implementations of the Common Lisp dialect
(ANSI Standard X3J13), not any other Lisp dialects, nor Scheme. The
primary design work for the initial Common Lisp was mainly 1982. Guy
L. Steele Jr. was the editor of the initial specification. He, Dave
Moon, Richard Gabriel, Scott Fahlman, and I were the primary
designers, although of course the design drew very heavily on
preceeding dialects. The ANSI X3J13 standard (formally, X3.226-1994)
was completed mainly in 1993, and published in 1994. It is about 1150
pages long. Papers about the history of Common Lisp are referenced
below (see "Resources").

In my opinion, having multiple supported implementations of a
language, rather than merely one canonical implementation, is a sign
of a robust and vibrant language. There are many Java implementations
(e.g. JRockit), many Python implementations (JPython, IronPython), and
so on. These Common Lisp implementations do a very good job of
meeting the official X3J13 language standard, and it's very easy,
often no work at all, to make an application developed in one run in
another if you stay within the defined language.

If you're maintaining a large body of Common Lisp software, it can be
helpful to regularly build it using two or more implementations of
Common Lisp, even if you only ship the code with one version. This is
because different compilers, and different runtimes, will sometimes
find (or provide clearer reports of) program errors than another
implementation. It's a little bit of extra work, but in the long run
it saves you time.

These are the implementations, in alphabetical order:

Name

a.k.a.

License

Platforms

Allegro CL

Commercial

Linux, Unix, Mac, Windows

Armed Bear CL

ABCL

GPL

Linux, Unix, Mac, Windows

CMU CL

CMUCL

Open

Linux, Unix, Mac

Clozure CL

OpenMCL

LLGPL

Linux, Unix, Mac

Corman CL

Commercial

Windows

Embedded CL

ECL

LGPL

Linux, Unix, Mac, Windows

GNU CL

GCL

LGCP, GPL

Linux, Unix, Mac, Windows

GNU CLISP

CLISP

GPL

Linux, Unix, Mac, Windows

LispWorks

Commercial

Linux, Unix, Mac, Windows

Scieneer CL

SCL

Commercial

Linux, Unix

Steel Bank CL

SBCL

BSD/Public

Linux, Unix, Mac

My deepest thanks to everyone who responded to the survey:

Allegro CL: Kevin Layer

Armed Bear CL: Peter Graves

CMU CL: Raymond Toy

Clozure CL: Andrew Shalit

Corman CL: Roger Corman

Embedded CL: Juan Jose Garcia-Ripoll

GNU CL: Camm Maguire

GNU CLISP: Sam Steingold, Bruno Haible

LispWorks: Dave Fox

Scieneer CL: Douglas Crosher

Steel Bank CL: Nikodemus Siivola, Christope Rhodes

Thanks to Bruce Tate for permission to quote his paper. Special
thanks to Pascal Costanza of Vrije Universiteit Brussel, Brussels,
Belgium, for all his wise advice and other invaluable help.

To the survey results, I have sometimes added small amounts of
material from the implementations' web site.

Note: I did not include in the survey Digitool, Inc.'s MCL. It is
still widely-used, but the level of maintenance disqualified it for
this survey. Alice Hartley recently announced that it will be
open-sourced shortly. The Lucid technology is now available from
LispWorks under the name Liquid Common Lisp, but as it is not
supported by the major portable libraries and tools, I chose to omit
it. (Also, Symbolics's Genera may re-appear, probably as open source,
someday, but is currently unavailable for all intents and purposes.)

No-cost (free/open) software is very popular these days, for obvious
reasons. However, I urge the reader not to make quick judgments.
Speaking of the period 1984-1992, Common Lisp co-designers Guy
L. Steele Jr. and Richard Gabriel said: "Though one might think a
free, good-quality product would easily beat an expensive
better-quality product, this proved false, and Common Lisp companies
thrived despite their no-cost competitor [they refer here to Kyoto
CL]. It turned out that better performance, better quality,
commitment by developers to moving ahead with the standard, and better
service were more important than no price tag." That was many years
ago. Kyoto CL was amazing -- it took us all by surprise, being
developed far away by two young Japanese researchers who had no
contact with the CL community at all -- although it left much to be
desired. The current no-cost implementations are far better than
Kyoto CL was then, both in terms of software quality and maintenance.
My only point here is that you should not draw premature conclusions.

Also, don't compare version numbers across implementations. Some
version numbering systems are modest. If the implementation says that
it's version 1.0.23, that should not be taken to mean anything at all
about the age or maturity of the implementation.

Allegro CL

Allegro Lisp is a product of Franz Inc. The current release is 8.1.
There is a large group of maintainers (more than 10). There is a
highly optimizing native compiler on all platforms.

Allegro Common Lisp was originally called Extended Common Lisp, first
released in 1985. It is written in itself, and we used Franz Lisp
(another dialect of Lisp that Franz used to sell in the 80's) to
bootstrap the new implementation.

The compiler and runtime system were written from scratch, but some of
the interpreter came from CMU's Spice Lisp. Our CLOS implementation
was originally based on Xerox PCL. The interpreter and CLOS
implementations were rewritten over the first few years of the
product's life. An extensive history of Franz, Inc. can be found at
http://franz.com/about/company.history.lhtml. The principal founders
of Franz were Fritz Kunze, John Foderero, and Richard Fateman. John
Foderero, the original primary architect at Franz, is still there as
Chief Scientist.

It runs on the following platforms:

32-Bit:

Apple Mac OS X/PowerPC

Apple Mac OS X/Intel

FreeBSD/x86

HP-UX/PA-RISC

HP Tru64/Alpha

IBM AIX/PowerPC

Linux/x86

Microsoft Windows/x86

Sun Solaris/SPARC

64-Bit:

Apple Mac OS X/PowerPC

Apple Mac OS X/x86-64

HP Tru64/Alpha

HP-UX/PA-RISC

IBM AIX/PowerPC

Linux/x86-64

Microsoft Windows/x86

Sun Solaris/SPARC

Sun Solaris/x86-64

It is distributed in binary form, in the native format for each operating system.

Allegro CL is not open-source, but much of the source code is
available to customers, who must sign a license agreement. Some of
our source is open (e.g., AllegroServe). Open-source products from
Franz use the LLGPL. Pricing for Allegro CL starts at $599. There is
a runtime fee. There are three editions:

Allegro CL Free Express Edition -- Feature set similar to the Professional version, heap limited (55MB).

Allegro CL Professional Edition -- Full featured Lisp, Professional version of AllegroCache.

Support for locating source code (Emacs m-.): Yes, both in SLIME and ELI.

Profiling: Yes, a statistical profiler.

Streams: Both Gray streams and simple streams.

Threads: On Windows we use the native threads. On other platforms we currently use our own threading library, but we do link against libpthread on UNIX systems that have it. We are working on native thread implementations for UNIX. A complete explanation of the behavior of threads, with respect to symmetric multiprocessing (ability to use more than one CPU or "core") can be found at http://www.franz.com/support/faq/#s-mp.

GC: Generational with many tunable parameters.

Unicode: Yes

CLIM: Yes, the unified implementation originally created with Symbolics

AllegroCache [http://www.franz.com/products/allegrocache/] -- a
high-performance, dynamic object caching database system. It allows
programmers to work directly with objects as if they were in memory
while in fact the object data is always stored persistently. It
supports a full transaction model with long and short transactions,
and meets the classic ACID requirements for a reliable and robust
database. It automatically maintains referential integrity of complex
data objects. AllegroCache provides 64-bit real-time data caching on
the application memory to achieve very high data access throughput by
applications over as large a data set as necessary. Some of the other
features include: bulk loading, transaction logging, expression
cursors, range queries, dynamic schema evolution, standalone &
client/server operation, native Lisp btrees (comparable in speed with
BerkeleyDB, with more control) that supports billions of objects (and
terabytes of data), maps, sets, XML export/restore, and user
controlled caching.

SOAP API [http://www.franz.com/doc/soap.htm] -- an implementation of
the SOAP client and server API, and given a web service WSDL
definition we can generate the Lisp functions and definitions needed
to send messages to the service and to receive and decode the replies.

Allegro Btrees [http://www.franz.com/products/allegrocl/acl_btrees.lhtml] --
a high performance btree implementation:
* Written completely in Lisp in order to get the best performance possible and the best integration into a Lisp program.
* Keys and values are simple vectors of type (unsigned-byte 8). If you wish to store other types of data you have to write encoder/decoders to/from (unsigned-byte 8) vectors.
* Extensive support for caching disk blocks to avoid disk I/O.

Allegro Prolog [http://www.franz.com/products/prolog/] -- a classic AI
programming language in Allegro CL for Logic Programming, with an
execution speed in excess of 1 Mlips and running essentially cons
free. It can also be used as a query language for AllegroCache and
AllegroGraph.

Update, December 2008: Franz continues to produce technology. They have released support for the Amazon Elastic Computing Cloud (EC2) (available to supported Enterprise Edition customers; for Express or Professional Edition, talk to Franz). They are also continuing to develop and enhanced their Integrated Development Environment (IDE).

Armed Bear CL

Armed Bear Common Lisp development is run by Erik Huelsmann, along
with a group of four principal committers and a growing group of
incidental contributors. The current version is 0.18.1 (releases are
bi-monthly so the number changes frequently); recent work has
focused on correctness issues and CLOS performance improvement.

It is unique in that it runs under the Java Virtual Machine. This
means it can take advantage of the highly-optimized Just-In-Time code
generators and garbage collectors in each Java implementation. It
also allows easy interoperability with Java, giving it access to a
very large library.

ABCL was originally intended to be an extension language for the j
editor (http://armedbear.org/j.html), but gradually developed into a
full Common Lisp implementation, in part so that Paul Dietz's ANSI
Common Lisp test could be used. ABCL is not a fork of any other
implementation, but it uses code adapted from several of the other
free CL's, most notably SBCL and CMUCL. The CLOS implementation
started out from Closette, but has changed very much since. From
their web site: "ABCL's CLOS is intolerably slow and does not handle
on-the-fly redefinition of classes correctly. There is no support for
the long form of DEFINE-METHOD-COMBINATION, and certain other required
CLOS features are also missing. Enough CLOS is there to run ASDF and
CL-PPCRE, if you're in no hurry."

It runs on any platform that supports Java 1.4 or later (which
basically means it runs everywhere).

It is distributed in source form.

ABCL is distributed under the terms of the GNU General Public License,
with a special linking exception. If you link ABCL with your own
program, then you do not need to release the source code for that
program. However, any changes that you make to ABCL itself must be
released in accordance with the terms of the GPL.

ABCL is still used in the j editor project, and j has a slime-like
facility for running Lisp shells. ABCL also works with emacs/slime.

Support for locating source code (Emacs m-.): Yes.

Profiling: Yes.

Streams: No.

Threads: Uses the underlying Java threads, which are native on platforms like Linux and Windows.

GC: The underlying Java GC.

Unicode: ABCL's string infrastructure supports Java's version of Unicode (a Lisp character is a boxed Java character), but CHAR-CODE-LIMIT is 256 and there is no support for external formats, so what you get is ISO-8859-1.

CMU CL

CMU Common Lisp is an open-source project. The current release is
19e, which arrived in May 2008 (There were new features and many, many
bug fixes, including many for double-double-float). There are three
primary maintainers, and at least six very active contributors, and
volunteers from the open source community. It has an optimized native
code generator. It is widely used.

CMUCL was originally developed at the Computer Science Department of
Carnegie Mellon University. The work was a small autonomous part
within the Mach microkernel-based operating system project, and
started more as a tool development effort than a research project. The
project started out as Spice Lisp, which provided a modern Lisp
implementation for use in the CMU community. CMUCL was funded by DARPA
under CMU's "Research on Parallel Computing" contract. CMUCL has been
under continual development since the early 1980's (concurrent with
the Common Lisp standardization effort). Most of the CMU Common Lisp
implementers went on to work on the Gwydion environment for Dylan. The
CMU team was lead by Scott E. Fahlman. The compiler was written by
Robert MacLachlan. In 1994, the project funding stopped, and so CMUCL
continues as a group of users and developers collaborating over the
Internet. Some of the active contributors have included Martin
Cracauer, Pierre Mai, Eric Marsden, Gerd Moellmann, Timothy Moore,
Raymond Toy, Peter van Eynde, and Paul Werkowski.

CMUCL features a sophisticated native-code compiler which is capable
of powerful type inferences, and generates code competitive in speed
with C compilers, a graphical source-level debugger using a Motif
interface, an interface to the X11 Window System (CLX), and a
sophisticated graphical widget library (Garnet), and an Emacs-like
editor implemented in Common Lisp.

The CLOS implementation is Xerox's PCL (Portable Common Loops), with
many modifications done by Gerd Moellmann.

The latest version, as of May 2008, is CMUCL 19e.

It runs on the following platforms:

32-bit:

Linux/x86 (Updated in 19e to build on Redhat FC9.)

FreeBSD/x86

MacOSX/x86 (Mac OS X 10.5 and later)

MacOSX/PPC

Solaris/SPARC

There is no 64-bit version.

There is an ongoing effort to port CMUCL to win32, but no public
source code or binaries are available at present.

It is distributed as pre-compiled binaries, and as source. It is
available as a .deb package for Debian GNU/Linux, in RPM format for
Red Hat/x86, and as a package for the Gentoo Linux distribution.

There are no fees or runtime licenses. It is in the public domain.

CMUCL works well with SLIME and Ilisp with emacs/xemacs.

Good native code compiler.

Fairly easy-to-use foreign function interface.

Decent access to low-level machine level stuff.

Native support for double-double floats. But perhaps no one but me
cares about that. :-)

Support for locating source code (Emacs m-.): Yes.

Profiling: Yes.

Streams: Both Gray streams and simple streams.

Threads: The x86 port has non-native threads. The other ports do not support threads.

GC: Generational GC. On the x86 it is precise. On other platforms it is conservative for pointers on the stack and otherwise precise.

Unicode: No, but there are plans to add Unicode support. (As of version 19e: Preliminary support for external formats. Currently only iso8859-1 and utf-8 are supported. Utf-8 support is limited since CMUCL only has 8-bit characters.

CLIM: No.

CLOS MOP: Yes, at least some of it.

Delivery system to help produce distributable applications: No. (There was once a tree-shaker, but it didn't seem to save very much so it was not incorporated.) You can build a version without the compiler, but that precludes using CLOS. You can build a version without CLOS.

Access to underlying operating system: FFI.

Clozure CL (OpenMCL)

Clozure Common Lisp is maintained by Clozure Associates, a software
development consulting company (http://www.clozure.com/). There are
two full-time maintainers, three part-time maintainers, and several
other contributors (some at Clozure, some not). The current version
is 1.4.

Clozure CL has a long history. It began at Coral Software as Coral
Common Lisp, which was initially released in 1987, and ran on a 1 MB
Macintosh Plus. Subsequently, Coral entered into a marketing
relationship with Franz under which CCL was renamed to Macintosh
Allegro Common Lisp (MACL). That didn't last long, and in 1989 Coral
was acquired by Apple, who released the Lisp under the name Macintosh
Common Lisp (MCL). In 1994, amidst a switch from the 68K to the
PowerPC CPU for its Macintosh line, Apple transferred MCL to Digitool.
Digitool completed the PowerPC port and released a PowerPC version of
MCL around 1995.

Erann Gat (now known as Ron Garret) of JPL wanted to develop a
small-footprint Lisp for use on PPC embedded systems in robots and
flight systems. A source license for MCL was acquired from Digitool,
and in 1998, Gary Byers ported a version of the MCL compiler and
runtime to VxWorks and LinuxPPC. In 2001, Digitool agreed to open
source the work that had been done at JPL, and OpenMCL was born.
Since then, a lot of development has taken place, funded both by
clients and directly by Clozure, including ports to several platforms,
MOP enhancements, native threads, Unicode, and a brand new Cocoa-based
IDE for Mac OS X (totally unrelated to MCL's IDE).

In 2007, Alice Hartley of Digitool announced that the code for the
original MCL would be released under an open source license. Largely
in order to avoid confusion with this newly open sourced version of
MCL, OpenMCL was renamed to Clozure CL (or CCL for short).

Clozure CL 1.4 runs on the following platforms:

Mac OS X 10.4 and later (ppc32, ppc64, x86, x86-64)

Linux (ppc32, ppc64, x86, x86-64)

FreeBSD 6.x and later (x86, x86-64)

Solaris (x86, x86-64)

Microsoft Windows XP and later (x86, x86-64).

The 32-bit x86 ports require a processor that supports the SSE2
instructions.

It is distributed in both binary and source form. The command-line
versions require manual installation (some script editing, setting a
PATH variable, etc). There is a version for Mac OS X that can just be
dragged to the Applications folder. In the future, there may be
separate "IDE" and "command-line" editions, but not yet.

Clozure CL is free software. It is distributed under the terms of the
LLGPL. Fee-based support for Clozure CL is available from Clozure
Associates on a per-incident or contract basis.

All the Emacs-based development packages (slime, ilisp, etc.) work
with Clozure CL. Also, the Mac OS X version has a GUI-based IDE
written in Lisp using the Mac OS X Cocoa framework.

Support for locating source code (Emacs m-.): Yes.

Profiling: Statistical profiling is available on some platforms using native tools (e.g., oprofile, Shark) along with a supplied utility to map from program counter to symbol names.

CLOS MOP: Mostly, with the exception of the generic function invocation protocol. MCL originally supported an object system called Object Lisp, which was used to implement the IDE, editor, and numerous tools. When it became clear that CLOS would be the object standard for Common Lisp, it made sense to convert all that code to CLOS. The MCL developers did not base their CLOS implementation on PCL (Portable Common Loops) because that would have doubled memory usage. Therefore the CLOS implementation was written from scratch by Gail Zacharias and Bill St. Clair. Unfortunately, AMOP wasn't out at the time, so certain implementation choices make some MOP features difficult to provide.

Delivery system to help produce distributable applications: Produces standalone executables on all platforms. On Mac OS X, it can produce double-clickable GUI applications (i.e. application bundles, with icons, etc).

Access to underlying operating system: A convenient native FFI provides an easy way to call foreign code. Calling a function in libc can be as simple as (#_getpid) or (#_lockf fd #$F_LOCK, 0). A separately available interface translator can enable the #_ reader macro to know about other foreign libraries, too. It is possible to write lisp functions that can be called from foreign code. On Mac OS X, an Objective-C bridge integrates Objective-C classes and methods into CLOS. The bridge allows bidirectional access to Cocoa (and other Objective-C libraries), including support for subclassing and adding methods to objects.

Clozure CL is small, fast, and mature. The compiler (which produces native code) is especially fast---rebuilding the entire lisp with itself takes less than a minute on modest hardware. More than 20 years of development by accomplished professional programmers has made Clozure CL a robust and stable system. Many of the original implementers (from Coral) still work on Clozure CL.

One particularly notable application that uses Clozure CL is ACL2 (A
Computational Logic for Applicative Common Lisp), a side-effect free
variant of CL with the Boyer-Moore theorem prover, from the University
of Texas. It particularly takes advantage of parallelization offered
by native threads. Also, Clozure CL's IDE, using the Objective-C
bridge, is written in Clozure CL.

Corman CL

Corman Common Lisp is from Corman Technologies, Inc. The current
version is 3.01. There is one primary developer and one other
developer.

Corman Lisp is particularly focused on Windows on the Intel
archicture. It features a native code compiler for Intel processors,
80x86 assembler and disassembler, incremental linker and multi-window
text editor. It is fully integrated with the Win32 API, and all the
Windows API functions are readily available from Lisp.

Corman CL was designed and implemented by Corman Technologies, since
1995. Previously they developed PowerLisp for the Mac, but Corman CL was
a complete rewrite for Windows. (PowerLisp is no longer developed or
supported). They have developed and maintained Corman CL
continuously, with new major releases approximately every 18 months
(and minor updates more often). The CLOS implementation was
originally from Art of the Metaobject Protocol Closette, and then
extensively rewritten to add missing Common Lisp features and to
improve performance.

It runs on the following platforms:

Windows (Vista/XP/2000/Windows Server 2003)

It will run on 64-bit Vista, in console mode. However, it does not
yet compile code to take advantage of 64-bits.

It is distributed in ready-to-install (includes a standard Windows
installer) and all pre-compiled. It includes project files that allow
users to rebuild it (rebuilding the kernel requires the Microsoft C++
compiler).

All source code is included in the release distribution.

The Corman Lisp compiler is free for personal use, and comes with full
source code (in Common Lisp, C++ and assembler). If you wish to use
Corman Lisp to create and distribute applications, or in an
educational setting, you must purchase a registered copy. If you wish
to use the IDE (editor and development environment) for more than 30
days you must purchase a registered copy. See the CormanLisp web site,
for details and to download the program:

Licenses are $249, educational discount licenses are $125. There are no
runtime license fees of any kind. Once a developer has purchased a
license, he or she may create applications and redistribute them or
sell them without paying any additional fees. There is only one
edition, but it is available either as free, regular license fee, or
educational license fee. Only users who have paid the license fee are
permitted to distribute Lisp applications. There are other license
issues and restrictions included in the installation package. In all
cases the distribution is complete and the same--but if the user has
not paid the license fee there are some times they will see "nagware"
dialogs suggesting they purchase a license.

A multi-windowed text editor for editing, compiling and executing
Corman Lisp programs is included. The IDE runs in a different thread
than Corman Lisp programs, always allowing full control even while
Corman Lisp is running. Note that the sources for this application
are not included in this package.

For Windows development, it has very good performance and very tight
integration with the operating system. Intel assembly code can be
easily embedded in lisp code, lisp code can call native, code, native
code can call lisp code, etc. The garbage collector is also very
efficient and multiple simultaneous threads are supported.

Support for locating source code (Emacs m-.): Yes, in the IDE you can right-click over any symbol and select "Find Source" and it will open the file with the source code for the operator and position the window at the correct location. This works both for built-in operators and any used-defined operators.

Profiling: Yes.

Streams: No, but some users have ported them.

Threads: Native Windows threads, including parallel processing.

GC: The garbage collector is precise (copying) and generational (and supports multiple threads). When garbage collection occurs all other lisp threads are halted. It works very similarly to the garbage collector in the Microsoft .NET CLR (ours was developed first). It includes support for finalization and weak pointers.

Unicode: Partially complete, will be provided in the future. All characters are 16 bits.

CLIM: No.

CLOS MOP: Some.

Delivery system to help produce distributable applications: There is a SAVE-APPLICATION function which creates an EXE file (executable) for Windows that can easily be redistributed. It includes all the loaded lisp functions (the entire image) but is stored in a compressed form in the executable which keeps the executable size down. You can create native DLLs as well as executable programs.

Access to underlying operating system: You can easily access any Windows OS feature. Full support for all Windows API (including COM) is included, and the RDNZL package from Edi Weitz is also included which allows Lisp to interact with .NET. Lisp functions can embed Intel assembly language if you really need to do low-level tweaking. The Foreign Function Interface supports definition of callback functions which can be used as Windows procedures or for other uses. This allows straight Win32 SDK applications to be built, exploiting the whole power of the operating system. These callbacks can be interactively edited and replaced, even while being used by the operating system or another program. Corman Lisp is built as an in-process COM server, and can be accessed as such to increase its flexibility for use in different programming environments. The included development environment interacts with Corman Lisp exclusively via COM interfaces. The COM interface information is included in the Corman Lisp sources in this package.

For someone's code (this is not from Corman Technologies) to make Corman CL work better with Emacs:

Embedded CL

Embedded CL is community-supported software. The current version is 10.2.1.
There is one primary developer, plus contributions from the open source
community.

It compiles Lisp functions into C functions that use the C stack and
standard procedure call conventions. This lets Lisp and C code be
easily mixed. It is designed to be used as a C library from any C
application. It is embeddable: prominent examples are plugins for
Mozilla (e.g. Firefox) and XChat. The code is rather clean and
maintainable. It is described as "quite fast". It produces standalone
executables for all environments, as well as shared libraries. It can
merge C and C++ code. It is described as "rather ANSI compliant".

ECL is based on the Kyoto Common Lisp. The history line is KCL ->
AKCL -> EcoLisp -> ECL -> ECL-Spain -> ECL. It was originally supported
by Giuseppe Attardi. The current maintainer is Juan Jose Garcia Ripoll.
The CLOS implementation is based on PCL. There
is a paper at:

It uses a byte code compiler and interpreter, and a translator to C.
It can build standalone executables and dynamically-linked libraries
that can be incorporated into other C-based programs. It uses the gnu
multiprecision library for fast bignum operations.

It runs on the following platforms:

Both 32-bit and 64-bit:

Windows

Linux

FreeBSD

NetBSD

OpenBSD

MacOS

It is distributed in source form (you need a C compiler), but
sometimes people make the Windows port available in binary form.

It is free, licensed with LGPL. There are no fees.

It is a full Common Lisp implementation. You can use it just fine
without doing any embedding at all. See

Gnu CL (GCL)

GCL has a very long history. It comes from Kyoto Common Lisp, which
was written in Japan by T. Yuasa and M. Hagiya, working alone (which
greatly impressed the Common Lisp community!). KCL used a compiler
that produced C code, which was then compiled into the appropriate
machine language. Later, William Schelter at University of Texas at
Austin did extensive modifications, the result of which was called
AKCL. It was officially adopted by the GNU Project, and is the basis
for many open-source Lisp projects, including acl2, axiom, hol88, and
nqthm. GCL is also one of the most common Maxima platforms. The CLOS
implementation comes from PCL.

The current version is 2.6.7. cvs tag "Version_2_6_8pre" is the next
stable release candidate.

The primary maintainer is Camm Maguire, and there are many
free-software volunteers. GCL development, like many open source
projects, proceeds in bursts. At such times, contributors number from
5 to 10.

Access to underlying operating system: Full access to underlying C interface and system calls.

Rather then using threads, GCL provides fork-based parallelism, with p-let, p-and and p-or. It's based on the Unix/Linux "fork" operation, which provides copy-on-write memory pages. This means the child process instantly inherits the parent's memory image, and the operating system only copies pages as they are modified (written) after the fork. GCL allocates on the C stack in the child to avoid GC calls there, which would write to many pages. The result is then printed in the child and read in the parent across a socket. It's quite fast, with a latency around 2ms. The huge advantage in avoiding threads lies in preserving a natural Lisp syntax and keeping all the internals under the hood. The user need not explicitly worry about locks, mutexes, memory corruption, reentrancy/thread safety, spaghetti stacks, etc. Any Lisp function which results in a printable result can be parallelized without modification in this way.

To make parallel programming easier, GCL supports MPI (Message Passing Interface), a standard library API used by mpich, lam, openmpim, et. al. It is used to synchronize data structures across many nodes in a parallel (e.g. "Beowulf" )computing cluster. This can also be used on a single machine to pass data via extremely fast SysV shared memory between processes.

Fast bignums, using the GMP MP library, which is widely regarded as the fastest bignum implementation in the open source world. GCL has closely integrated its internals to make optimal use of this library.

GNU CLISP

GNU CLISP is a free software project. The current release is 2.48,
released July 28, 2009. There are two or three (or five, depending on
how you count) primary maintainers, plus a community of volunteers.

It is particularly known for running Maxima (the free software
derivative of DOE Macsyma), using GNU CLISP's SCREEN package. It is
also famous for being used in the Viaweb (Yahoo! Stores) application.
It features a source-level debugger which allows stepping through
interpreted code, form by form.

The pre-history of CLISP started when Michael Stoll of Munich University read a couple of
articles by Martin Gardner (I think) on LISP in "Spektrum der
Wissenschaft", the German sibling of the Scientific American. He wrote
a Lisp implementation for the Sinclair ZX81. Later, he teamed up with
Bruno Haible of Karlsruhe University, and they implemented Common Lisp (based on the original
"Common Lisp: The Language") for the Atari/68000, first in assembly
language but later (1991/1992) in C. To fit in memory, they wrote a byte-code
compiler; much faster than the interpreter but not as good as
native code. Bruno put a lot of effort into very efficient arithmetic.
Sam Steingold is the current maintainer (or at least he's one of them).

The most recent release, which arrived in May 2008, is 2.45. It is
described as "It mostly supports the Lisp described in the ANSI Common
Lisp standard." (Please remember my statement at the beginning: I do
not know how closely each implementation adheres to the X3J13
standard.)

It runs on the following platforms:

GNU/Linux x86

GNU/Linux x86_64

GNU/Linux ia64

GNU/Linux sparc

GNU/Linux alpha

GNU/Linux arm

MacOSX PowerPC

MacOSX x86

FreeBSD x86

FreeBSD x86_64

NetBSD x86

NetBSD SPARC

OpenBSD x86

GNU/Hurd x86

GNU/kfreebsd x86

Solaris SPARC

Solaris x86

AIX PowerPC

HP-UX hppa

Tru64 alpha

IRIX mips

SINIX-N

SINIX-Z x86

BSDI x86

Cygwin x86

Windows x86 (Windows NT/2000/XP/Vista)

NeXTstep m68k

BeOS x86

It is distributed in binary form for the most important platforms,
and in source form. It also comes with most GNU/Linux distributions.
It's available from the "BSD ports" sites.

The available development environments are: simple command line
(supported through the GNU readline library), Emacs SLIME, Emacs
inferior-mode, Jabberwocky.

It features a small start-up time and only needs 4MB of RAM. It has
particularly good, high-speed support for bignums and
arbitrary-precision floating point, ideal for scientific computation.
It has regular expressions, a socket interface, and an X11 Window
System interface (through CLX, Garnet, and CLUE (CL User Interface
Environment) and CLIO (CL Interactive Objects)). There is a "module"
facility allows for easy interfacing to external libraries.

It has a native JIT compiler, based on GNU Lightning.

Support for locating :source code (Emacs m-.): No.

Profiling: Yes.

Streams: Gray streams.

Threads: Experimental only, in the development sources (cvs head), using native threads.

GC: Generational, precise, and fast.

Unicode: Yes (all strings are UCS-4).

CLIM: McCLIM is supported.

CLOS MOP: Mostly. ("Except the broken parts of the MOP. And with extensions that are in the spirit of MOP.")

Delivery system to help produce distributable applications: Applications can be saved as standalone executables.

Access to underlying operating system: There are bindings to OS functions (POSIX, Win32) and to GTK2.

The user interface comes in English, German, French, Spanish, Dutch,
Russian and Danish, and can be changed at run time. It includes a
foreign language interface, a socket interface, I18N
(internationalization) support. It runs Maxima, ACL2, and many other
Common Lisp packages.

LispWorks

Development began in Cambridge, England in 1987 and continues there
today. The various owners have been: 1987-2000 Harlequin, 2000-2004
Xanalys, and 2005-present LispWorks Ltd.

The CLOS implementation started out as a branch of PCL (Portable
Common Loops).

The current version is 6.0.

It runs on the following platforms:

Windows x86-32

Windows x86-64

MacOS PowerPC (32-bit LispWorks is a universal binary running on both Mac hardwares)

MacOS x86

MacOS PowerPC-64 (64-bit LispWorks is a universal binary running on both Mac hardwares)

MacOS x86-64

Linux x86-64

Linux x86-32

FreeBSD x86-32

Solaris Sparc-32

Solaris Sparc-64

Solaris x86-32

Solaris x86-64

HP-UX HPPA

The source code is generally not available. However, most of the
editor source is distributed with commercial editions of LispWorks to
allow customers to write extensions and customizations in the same way
that Emacs users do. Distributions are all already-compiled.

LispWorks is available in three editions:

LispWorks Personal Edition: Includes the full Common Lisp compiler and most of the IDE. It limits the heap size to around 70MB. It limits session duration to 5 hours. It does not include application delivery.

LispWorks Professional Edition: Suitable for commercial Common Lisp software development and application delivery. Includes CLIM on Windows and X11/Motif.

LispWorks Enterprise Edition: All the Professional Edition features plus database access through Common SQL, distributed computing through LispWorks ORB, and expert system programming through KnowledgeWorks (r).

Development Licensing: A single LispWorks Professional (32-bit)
Edition development license for commercial use costs US$1500 / 1200
Euro at the time of writing. A single LispWorks Enterprise (64-bit)
Edition development license for commercial use costs US$4500 / 3600
Euro at the time of writing. LispWorks Enterprise (32-bit) Edition is
also available, separately licensed at the same price.

Maintenance and support contracts are available as optional
extras. Discounted license fees are offered to academic
institutions. Quantity discounts and site licenses are
available. Current prices are shown at:

Support for locating source code (Emacs m-.): Yes, including support for locating your own defining forms.

Profiling: Yes, in the read-eval-print loop, and also in a graphical profiler with cumulative and call-tree views.

Streams: Yes, Gray streams.

Threads: Supports symmetric multiprocessing (SMP) on Intel-based platforms: Lisp can run in multiple threads at the same time on multi-processor hardware. Native threads are used on all other platforms (except SPARC and HP-UX where non-native threads are used) and Lisp can run in at most one thread at a time. See http://www.lispworks.com/documentation/lw60/LW/html/lw-228.htm.

GC: Precise and generational, on all platforms.

Unicode: Yes

CLIM: Yes, on Windows and X11/Motif.

CLOS MOP: Yes, LispWorks supports the MOP as specified by "The Art of the Metaobject Protocol". A few discrepancies are documented.

Delivery system to help produce distributable applications: Yes. LispWorks application delivery includes a treeshaker (which finds out which portions of Common Lisp are actually used by the program, and only delivers those). It can generate a distributable executable on all supported platforms. On all popular platforms LispWorks can also generate a dynamic library.

Access to underlying operating system: On Macintosh there's a predefined Objective-C/Cocoa API. On Microsoft Windows, LispWorks provides a COM/Automation API. You can extend the APIs provided by using the Foreign Language Interface. You can write a GUI application using CAPI, a built-in Lisp library which uses the native windowing system (Cocoa, Windows, GTK+) for the platform.

There is a growing list of successsful applications built on LispWorks at:

An especially interesting one is InspireData, data visualization
software written by Clozure Associates, under contract with TERC, in
LispWorks. Originally funded by the National Science Foundation,
InspireData lets students in grades 4-12 tools visualize, investigate
and understand data in science, mathematics, and the social
sciences. In its first six months of release, InspireData sold over
20,000 copies, establishing it the most widely distributed Common Lisp
application.

Scieneer CL

Scieneer CL is produced by Scieneer Pty Ltd of Australia. The current
version is 1.3.7. There is one primary developer.

It is a fork from CMU CL, with improvements focusing primary on
high-performance scientific computing.

Scieneer Pty Ltd was formed in March 2000 to develop and support a
professional Common Lisp implementation for Symmetrical
Multi-Processor (SMP) systems which is a key requirement for many high
performance computing and enterprise applications.

The company was founded by Douglas Crosher, who was a developer
of CMU Common Lisp. He was responsible for the x86 port, the
generational garbage collector, the multi-processing support, and
other enhancements.

SCL 1.1 was publicly released in September 2002. The SCL 1.2 version
was released in September 2003, adding support for 64-bit platforms,
and integrating high performance HTTP support. The SCL 1.3 version was
released in April 2006 consolidating many improvements and adding
support for the Solaris x86 and 64 bit AMD64 platforms.

It also features integrated, high performance, and scalable HTTP
support; stream input and output functions are designed for high speed
buffered character or octet operation; SSL support (built on OpenSSL)

It runs on the following platforms:

32-bit:

Linux x86

Solaris x86

Solaris SPARC

HPUX 11.11 HPPA

64-bit:

Linux AMD64

Solaris AMD64

Solaris SPARC

HPUX 11.11 HPPA

It is distributed in binary form; sources are not available. It is
sold as a customized package of licensing and support, generally with
per-processor core licensing. There is no distinction between
development and runtime. Value-added and embedded licenses can be
negotiated. Scieneer says "there are a wide range of licensing and
support options that we will consider, so please contact us to discuss
licensing and support options." Some prices are presented at:

Streams: Yes, streams are CLOS classes and can be extended by defining new classes and methods. They are very fast. Some degree of compatibility with Gray streams. Far superior to 'simple streams'.

Threads: Native.

GC: Generational. Largely precise, but some roots are scavenged conservatively.

Unicode: Yes

CLIM: No.

CLOS MOP: Largely.

Delivery system to help produce distributable applications: No.

Access to underlying operating system: Yes. The multi-threading extension is built on the native threading support of the computing platform which allows Common Lisp code to work cooperatively with foreign functions and libraries and also allows foreign code to run in parallel with Common Lisp code. For example, database queries sent via foreign libraries can run in parallel with other Common Lisp code. It includes support for named callbacks into lisp. The two popular freeware Common Lisp foreign function interfaces (CFFI and UFFI) are fully supported by the Scieneer CL, and compatibility is largely maintained with the popular free CMU CL implementation. This support makes it easier to port code to the Scieneer CL and a large range of freeware software has been ported.

Steel Bank CL (SBCL)

Steel Bank CL (SBCL) forked from CMU CL in December, 1999. The fork
was initiated by William Newman. The system is named after the
industries where Andrew Carnegie and Andrew Mellon, respectively, made
fortunes.

The original goal of the fork was to produce a version of CMU CL that
was easier to build and to maintain. After the fork, SBCL diverged
from CMU CL, and as can be seen in this survey there are significant
differences between their feature sets these days. While SBCL and CMU
CL still share a lot of common code, few changes to one system are
ported over to the other. Due to this and the different development
philosophies, it can be expected that the implementations will
continue to diverge.

The CLOS implementation is based on PCL, but has been substantially
modified. The compiler generates reasonably good machine code: good
for low-level number crunching as well.

SBCL is a volunteer driven project, with no formal controlling
organization. During the last year code from approximately 40 persons
were merged into SBCL. Of course the level of activity of the
individual contributors varies greatly, with the top five accounting
for around 75% of the changes. William Harold Newman, Christophe
Rhodes, Nikodemus Siivola, and Juho Snellman have been major
contributors in the last few years. See:

There is a Windows port, but it is not quite ready for prime time. It
can be used for development work. However, it has some limitations.
(a) SBCL expects to be able to map various important constants (NIL,
T, a few other things) into hard-coded addresses, and this isn't
always possible on Windows, so SBCL sometimes won't start on some
people's hosts. Rebooting the host or recompiling SBCL with a few
changed magic numbers often does the trick. (b) SBCL doesn't yet have
threading on Windows (it's being worked on, though). (c) There are
some bugs and missing bits having to do with I/O. (d) 64-bit SBCL for
64-bit Windows is not yet ready.

Binaries are available for all supported platforms, but are generally
not made for all platform/release combinations. Thus to get a
reasonably new version for some of the rarer platforms will require
compiling one.

It is distributed in both binary and source form. The licensing is
BSD-style for a few subsystems, and public domain for the rest. There
are no fees.

The default SBCL distribution does not include an IDE. Slime is most
often used. Due to the overlap between SBCL and Slime contributors,
new SBCL features are often integrated to Slime immediately. The
Eclipse Lisp IDE Cusp is based on SBCL and the socket protocol of
Slime. It provides a read-eval-print loop, a project manager, an
outline of your code for simple navigation, a code editor, syntax
highlighting, auto-indentation, parenthesis matching, auto-completion,
library management, and more.

Steel Bank Studio Ltd exists to provide support and development.

Support for locating source code (Emacs m-.): M-. works on most standard definition macros (e.g. functions, methods, macros, classes, packages, types and variables). A programmatic interface is also available to this information.

Profiling: Yes. SBCL includes two profilers. One classical instrumenting profiler, and one statistical profiler with call graph support.

Streams: Gray streams are supported. A half-baked implementation of simple streams is included as a contrib module, but not widely used.

Threads: Native threads are supported on most Unix-like operating systems on x86 and x86-64 architectures. There is no thread support for other architectures. SBCL is able to run multiple Lisp threads concurrently on multiprocessor hardware. (There is a project to add Windows thread support over the summer of 2008).

GC: On x86 and x86-64 SBCL uses a generational mostly copying conservative garbage collector. On PPC it uses a precise generational copying collector. On other architectures it uses a precise non-generational semispace collector.

Unicode: Yes.

CLIM: Not bundled, though in a similar manner to Slime, the McCLIM community project shares many developers with SBCL developers and users, and consequently is frequently tested against new SBCL releases and can use new SBCL functionality quickly.

CLOS MOP: Yes. Specifically, where the description in "The Art of the Metaobject Protocol" (AMOP) is unambiguous, and no compelling reason exists not to, not conforming with AMOPs description of the MOP is treated as a bug. Pascal Costanza's MOP feature conformance tests have greatly helped here, to the point that his "Closer to MOP" compatibility layer for SBCL consists solely of two utility function definitions. Additionally, SBCL is beginning to explore the possibility of exposing MOP facilities that AMOP does not include, such as user-defineable specializers (as in a paper at the ECOOP Lisp workshop by Christophe Rhodes) and generic function sealing (current work by Paul Khuong).

Delivery system to help produce distributable applications: It can produce "stand-alone" executables, but unless gzexe'd they are fairly large.

Access to underlying operating system: A reasonably complete POSIX interface is included as a contrib module.

It is notably use in ITA Software's "QPX" airline low-fare search engine,
a very large application that is used by Orbix and many airlines.

SBCL is one of the highest performance Common Lisp implementations.

SBCL includes a modern code coverage tool.

SBCL includes a cross-referencing facility, with Slime integration.

SBCL supports the extensible sequence protocol proposed by Christophe Rhodes, which allows users to subclass SEQUENCE, and have the standard sequence operations work on instances of these classes.

For commercial SBCL support and custom development, see Nikodemus
Siivola's company:

Support by Some Major Libraries and Tools

This table shows which implementations are supported, and/or have been
tested, by some of the prominent Common Lisp libraries and tools.
This table should be seen as information about the libraries and
tools, rather than on the implementations. If an implementation is
not supported/tested, it may be quite easy to add support, or it might
even just work, so don't assume that a "No" is necessarily a big
problem.

Most Common Lisp libraries work on all Common Lisp implementations.
This is why I omitted such important facilities as ASDF. The ones
mentioned here are special because they depend on facilities that are
not (yet) standardized in Common Lisp, mainly access to features of
the underlying operating systems, or just because their documentation
was explicit and complete regarding implementations.

Name

Slime

McCLIM

Bordeaux

Araneida

Hunchentoot

UnCommon Web

clocc

GBBopen

LTK

FSet

Allegro CL

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Armed Bear CL

Yes

No

Yes

Yes

No

No

No

No

No

No

CMU CL

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Clozure CL

Yes

Yes

Yes

Yes

Yes

Yes

Some

Yes

Yes

Yes

Corman CL

Yes

No

Yes

No

No

No

Some

No

No

No

Embedded CL

Yes

No

Yes

No

No

No

No

Yes

Yes

No

GNU CL (GCL)

No

No

No

No

No

No

No

No

No

No

GNU clisp

Yes

Yes

No

Yes

No

Yes

Yes

Yes

Yes

Yes

LispWorks

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

Scieneer CL

Yes

No

No

No

No

No

No

Yes

Yes

Yes

Steel Bank CL

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Slime, by Eric Marsden, Luke Gorrie, Helmut Eller, Marco Baringer, and many others, is an interactive development environment for Common Lisp that runs inside GNU Emacs.

McCLIM, by Mike McDonald, is an open-source implementation of CLIM, a portable library for constructing user interfaces.

Bordeaux, by Greg Pfeil, is a standard API for threads in Common Lisp.

Also, Rainer Joswig did a survey, similar to this one, specifically directed to MacOS. He wrote it in October 2003 for the International Lisp Conference of 2003, and last updated it in November of 2007. A slightly earlier version can be found at:

Glossary

Some of the terms used above may be unfamiliar to some readers.

"ASDF", which stands for "Another System Definition Tool", is a very
widely-used Common Lisp package for compiling and loading programs.
Basically, it's Common Lisp's answer to the Unix "make" facility.
Nearly all Common Lisp packages are defined using ASDF.

"Bignum" means an arbitrary-precision integer. A bignum can represent
any integer, with no limit (until all of virtual memory runs out).
All Common Lisp implementations are required to support bignums, but
implementing them very efficiently is difficult. Some
implmenentations have put more effort into this area than others.

"CLIM" is powerful Lisp-based programming interface that provides a
layered set of portable facilities for constructing user
interfaces. These include basic windowing, input, output, and graphics
services; stream-oriented input and output extended with facilities
such as output recording, presentations, and context sensitive input;
high level "formatted output" facilities; application building
facilities; command processing; and a compositional toolkit similar to
those found in the X world that supports look and feel independence.

"CLOS" is the Common Lisp Object System. This is the part of Common
Lisp that provides object-oriented programming. It is based on two
predecessors: New Flavors, mainly by David A. Moon, which was in turn
based on the original Flavors, mainly by Howard Cannon; and
CommonLOOPS from Xerox PARC, mainly by Gregor Kiczales and Danny
Bobrow. The most comprehensive explanation of CLOS is the textbook by
Sonya Keene mentioned below. Sonya Keene was one of the original
committee that designed CLOS, and is one of the best technical writers
in the world.

A "conservative" garbage collector does not always know which memory
locations might contain pointers to objects, and is sometimes required
to preserve storage that it not really made of Lisp objects. A
"precise" garbage collector always knows.

"Foreign" means any programming language other than Lisp (when used in
"foreign function call"), or any natural language other than English,
depending on context.

"FTP" stands for File Transfer Protocol. This is one of the earliest
standard Internet protocols (actually predating the Internet itself!),
used for transferring files from one computer to another. Ordinary
browsers let you perform FTP transfers by using a URL whose scheme
is "ftp", e.g. "ftp://ftp.gnu.org/pub/gnu/clisp/".

"GC" means garbage collector, the subsystem that frees up memory
that is no longer in use.

A "generational" garbage collector keeps track of recently-created
objects, which are the most likely to be garbage. Almost all new GC's
are written using this technology.

"GPL" means the Gnu Public License.

"Gray Streams" (see also "Simple Streams") is an interface that allows a
programmer to define a new kind of I/O stream, that can be used with
all of Common Lisp's I/O functions such as readline and format. "Gray
Streams" was proposed to X3J13 for inclusion in the Common Lisp
standard by David N. Gray, then of Texas Instruments. It is supported
by Allegro CL, CMUCL, Clozure CL, Embedded CL, GNU clisp,
LispWorks, and SBCL. The official definition can be found at:

"I18N" means "internationalization", which usually means libraries and
other facilities designed to help you write programs that adhere to
conventions that differ between countries. The most important is
support for alternative character encodings, and usually UNICODE. It
can also include support for different formats of printing dates,
currency units, and so on.

"LGPL" means the "Lesser" Gnu Public License. The LGPL permits you to
link the libraries to "non-free" software without forcing that
software to be released under the GPL. See:

"LLGPL" means the "Lisp Lesser" Gnu Public License, like the LGPL with
a prequel which defines the effect in terms more typically used in
Lisp programs. The obligation to allow for relinking doesn't apply
(this was really targeted at the C paradigm).

"MOP" is the meta-object protocol for CLOS. It is not a part of the
Common Lisp standard, and there some some small ambiguities in the
specification itself, but it is so useful that many CL implementations
provide some or all of it. The ultimate reference explanation of the
MOP is "The Art of the Metaobject Protocol" by Gregor Kiczales
et. al., from MIT Press. But this is heavy reading and you can find
simpler introductions (see Papers, below).

"PCL" refers to the Portable Common Loops implementation of CLOS,
originally written primarily by Gregor Kiczales at Xerox Palo Alto
Research Center (PARC). Many Lisp implementations based their CLOS
implementation on this code base. In addition to the implementations
described in this paper, PCL was also used in AKCL, Ibuki, Lucid CL,
Medley, Symbolics Genera, and Symbolics CLOE.

"Scheme" is a programming language closely related to Lisp, sometimes
called the second main dialect of Lisp. It was originally designed by
Guy Steele and Gerald Sussman, at the MIT Artificial Intelligence Lab,
in the late 1970's. The most widely-used version is called R5RS; the
emerging new version is R5RS. Scheme is clean and minimalist, and provides
first-class continuations. It is widely used in college curricula.

"Simple Streams" is like "Gray Streams" (q.v.), but it's a different
interface, intended to avoid some problems with Gray streams. It was
originally designed by Franz, Inc. It is supported by Allegro CL,
CMUCL, and SBCL. Documentation can be found at:

"Threads" run concurrently. "Native threads" mean threads provided by
the operating system. "Non-native threads" (sometimes called "green"
threads) are provided by a library that runs above the level of the
operating system. The main advantages of native threads are that
other threads can continue to operate when one thread is waiting at
the operating system level (e.g. doing I/O); on multi-processor
systems, threads can run truly-concurrently utilizing up to as many
processors as the hardware provides; interoperability with foreign
code work better. The main advantage of non-native threads is that
thread-switching overhead is lower. Native threads are also called
"preemptive threads", and non-native are also called "cooperative
threads", which are better terms insofar as they focus on what
behavior you see rather than how the behavior is implemented.

Native threads are used by Allego on Windows, Armed Bear CL, Clozure CL, Corman CL, ECL, Scieneer CL, LispWorks on all platforms except SPARC and HP-UX, and by SBCL on Unix-like operating systems on the x86 and x86-64 architectures.

Non-native threads are used by Allegro on non-Windows platforms, CMUCL on the x86, and LispWorks on the SPARC and HP-UX.

Threads are not supported by CMUCL on non-x86, GNU clisp, and SBCL on non-x86.

"Unicode" is a representation of characters and strings that allows
international character sets, rather than simply the "Latin" set. It
is supported by Allegro CL, Clozure CL, partly in Corman CL, GNU
clisp, LispWorks, Scieneer CL, and SBCL.

Tutorials

"Common Lisp: First Contact", an easy-to-read, short tutorial for
Common Lisp, by Sven Van Caekenberghe.

A video talk on CLOS by Daniel G. Bobrow, one of the creators of CLOS,
about 50 minutes, discussing the history, design criteria (why CLOS
was designed the way it was), principal language features, and
metaobjects:

"Tutorial on Good Lisp Programming Style", by Peter Norvig (Sun Labs)
and Kent Pitman (Harlequin, Inc.), presented at the Lisp Users and
Vendors Conference, August 10, 1993. This is half-way between a book
and a set of overhead slides, 116 pages in all. It's in PostScript
and can be viwed with tools such as GSView from Ghostgum Software:

"Lisp and elements of style", by Nick Levine, are notes for a lecture
course, with exercises. It has a lot of conceptual background,
explaining the motivations and principles of basic features of Common
Lisp.

"Lisp as an Alternative to Java", Erann Gat (Ron Garret) of NASA's Jet Propulsion
Lab. A short study showing Lisp programs were shorter, took less time
to develop, and actually ran faster than the same programming tasks in
C++, let alone Java:

"Lisp: Good News, Bad News, How to Win Big", by Richard Gabriel, one
of the co-designers of Common Lisp. This paper was published in 1991
and so its particulars are out of date. It is a somewhat
philosophical examination of good and bad points of Lisp, with
suggestions for future directions:

"The Art of Lisp & Writing", by Richard Gabriel, originally written as
a foreword for Lamkins's "Successful Lisp" (see above) compares
programming with mapmaking and even poetry. It then talks about the
use of Lisp as a prototyping language. "Lisp, viewed this way, is a
good vehicle for understanding how programming and software
development really take place. Because programming Lisp is more like
writing than like describing algorithms, it fits with how people work
better than the alternatives."

"CFFI: The Common Foreign Function Interface" is very complete. CFFI
is supported by most of the Common Lisp implementations described in
this paper; the site goes into complete detail about implementation
support.

"UFFI: Lisp Universal Foreign Function Interface" is very complete.
UFFI is supported by most of the Common Lisp implementations described
in this paper; the site goes into complete detail about implementation
support.

"Lisp: A Language for Stratified Design", by Harold Abelson and Gerald
Jay Sussman, MIT AI Memo 986, August 1987, is a short paper
illustrating the power of Lisp as language for expressing the design
and organization of computational systems. The paper actually uses
Scheme, but it's easy to see how to do the same thing very analogously
in Common Lisp.

Documentation for the LispWorks CAPI system. Although this library is
implementation-specific, it is of great interest, because of its large
role in letting you write applications that look native. The CAPI
currently runs under X Window System with GTK+ and Motif, Microsoft
Windows and Mac OS X. It creates real native items such as buttons.

Success Stories: successful products and projects written in Lisp

Many successful products and projects were/are written in Lisp.
These sites tell about many of them.

[TODO: Put in descriptions!]

SPIKE is the planning and scheduling software used in support of the
Hubble Space Telescope. SPIKE is written in Allegro CL and has been
made available as a general toolkit for planning and scheduling under
Contract NAS5-26555 with the National Aeronautics and Space
Administration.

"Little b" is a biology-specific language for producing computer
models of biological systems. It's a classic example of how Lisp can
be used to create domain-specific languages, in part by using Lisp
macros:

AgentSheets AgentSheets is a revolutionary tool that lets you create
your own agent-based games and simulations and publish them on the Web
through a user-friendly drag-and-drop interface. It was created by
Alexander Repenning. It is the only Lisp-based tool that has ever
become required technology in public schools.

Common Lisp Textbooks Available On-Line

"Common Lisp: The Language, 2nd Edition" by Guy L. Steele Jr., full
text. This was the basis of the Common Lisp specification, but
further changes were made in the X3J13 ANSI standardization process,
so it's not quite the last word:

The author describes this as "one of the most hardcore computer
programming books out there. Starting with the fundamentals, it
describes the most advanced features of the most advanced language:
Common Lisp. Only the top percentile of programmers use Lisp and if
you can understand this book you are in the top percentile of Lisp
programmers." It focuses on Lisp macros.

"How to Design Programs: An Introduction to Computing and Programming"
by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and
Shriram Krishnamurthi is actually in Scheme rather than Common Lisp,
but it's such an excellent book on programming that it's well worth
reading:

These web sites are repositories of information about Common Lisp.
From them, you can find a huge number of free software libraries
and links to other useful sites. There are also URL's for Lisp
communities, job posting sites, etc.

The Common Lisp Directory, everything about Common Lisp: software, people, FAQ's, conferences, etc.

Starter package (Common Lisp with batteries included). This is a way to get a whole Common Lisp environment, on Windows, based on LispWorks Personal Edition and its interactive development environment (rather than SLIME).

Lispbox: A distribution containing a Common Lisp implementation, GNU Emacs, SLIME, ASDF, the code from Practical Common Lisp ready to be loaded using ASDF, and some glue code to make it all easier to use. By Peter Seibel.

The Association of Lisp Users, an international organization whose
mission is: to support the Lisp community by hosting an annual
conference and providing administrative support for Lisp-related
projects and local user groups:

"The ALU Website Map" contains links to many high-quality articles discussing Lisp language issues such as "compiled/interpreted", "strong/weak typing", "memory management", "macros", "language comparisons", etc., as well as links to tutorials and books and so on.

This newsgroup is a general discussion of Lisp, primarily about Common
Lisp. Many people monitor the newsgroup. It's a good place to get
questions answered. However, please do not use it to cheat on
your school homework by getting someone else to do it for you:

Videos from Eric W. Normand, that show you step by step how to build a
Reddit-like web application in Common Lisp. It uses Edi Weitz's
Hunchentoot library, a sophisticated HTTP server, and the cl-who
library to generate HTML.

ABLE is a Common Lisp environment for Linux, Windows and MacOS X
featuring tabbed editing, a Lisp listener with command history, symbol
completion, syntax highlighting, parenthesis matching, automatic
indentation, call-tips and Hyperspec lookup. It is written entirely
in Common Lisp, using LTK (which interfaces to the Tk toolkit). It
supports CLISP, SBCL, and CCL (Clozure Common Lisp, formerly known as
OpenMCL). By Phil Armitage.

Ready Lisp is a binding together of several popular Common Lisp
packages especially for Mac OS X, including: Aquamacs, SBCL and
SLIME. Once downloaded, you'll have a single application bundle which
you can double-click -- and find yourself in a fully configured Common
Lisp REPL. By John Wiegley.

Music software developed at the Stanford University Center for
Computer Research in Music and Acoustics (CCRMA, pronounced like
"karma"), much of it by noted composer and software expert Bill
Schottstaedt:

Lars Rune Nostdal's SymbolicWeb: Common Lisp Web Framework using AJAX
and Comet, based on Hunchentoot, and jQuery on the client
side. SymbolicWeb allows for two way real-time communication between
server and client. Updates or changes can propagate from the server to
the client at any time (Comet), while AJAX is used to send messages or
events the other way around.

Alexander Repenning's "Open Agent Engine", a Common Lisp interface to
the OpenGL 2D/3D graphics library. OpenGL is an extremely powerful
and popular standard graphics specification, for which there are
implementations all all major operating systems. It is licensed under
LGPL. It runs on Clozure CL and Allegro CL (and the
no-longer-maintained Macintosh CL). See:

BKNR is a set of Common Lisp libraries which together form an
environment suitable for serving HTTP clients from a persistent Lisp
system. BKNR is a pragmatic environment used to create systems for
real world users. The major code components of BKNR are:

Climacs is an Emacs-like editor built on CLIM, that has good
integration with other CLIM-based applications. Specialized editors,
such as for editing music (see "Some Lisp tools for musicology" by
Lewis and Rhodes, 2006). Troels "Athas" Henriksen is the principal
developer/maintainer.

The Beauty of Lisp

And finally, a lovely mini-essay about Lisp, by Bruce Tate, from his
paper, "Crossing Borders: The Beauty of Lisp, the El Dorado of
Programming Languages":

Lisp has long been recognized as one of the great programming
languages. The fanatical following it has inspired throughout its long
history -- nearly 50 years -- tells you it's something special. At
MIT, Lisp plays a foundational role in the curriculum for all
programmers. Entrepreneurs like Paul Graham used Lisp's incredible
productivity as the jet fuel for successful startups. But to the
chagrin of its followers, Lisp never made it into the mainstream. As a
Java programmer, if you spend some time with Lisp -- this lost city of
gold -- you'll discover many techniques that will change the way you
code, for the better.

I recently finished my first marathon and found running much more
rewarding than I ever could have expected. I turned an act as simple
as taking a step into something extraordinary for the human body,
running 26.2 miles. Some languages, like Smalltalk and Lisp, give me a
similar feeling. For Smalltalk, the step is the object; everything in
Smalltalk deals with objects and message passing. With Lisp, the
foundational step is even simpler. This language is composed entirely
of lists. But don't let the simplicity fool you. This 48-year-old
language comes with incredible power and flexibility that the Java
language can't begin to match.