Common Lisp Implementations in 2023

Much has been written on Common Lisp; there is rarely one year without someone
proclaming the death of the language and how nobody uses it anymore. And yet
it is still here, so something must have been done right.

Common Lisp is not a software, it is a language described by the ANSI INCITS
226-1994 standard; there are multiple implementations available, something
often used as argument for how alive and thriving the language is.

Let us see what the 2023 situation is.

General information

Note that all projects may have small parts with different licenses. This is
particularily important for CLASP which contains multiple components imported
from other projects.

I was quite surprised to see so many projects with recent releases. Clearly a
good sign. Let us look at each implementation.

Implementations

SBCL

Steel Bank Common Lisp was forked from CMUCL in December 1999 and has since
massively grown in popularity; it is currently the most used implementation by
far. Unsurprisingly given its popularity, SBCL is supported by pretty much all
Common Lisp libraries and tools out there. It is well known for generating
fast native code compared to other implementations.

The most important aspect of SBCL is that it is actively maintained: its
developers release new versions on a monthly basis, bringing each time a small
list of improvements and bug fixes. Activity has actually increased these last
years, something uncommon in the Common Lisp world.

CCL

Clozure Common Lisp has a long and complex
history and has been around for
decades. It is a mature implementation; it has two interesting aspects
compared to SBCL:

• The compiler is much faster.
• Error messages tend to be clearer.

This is why I currently use it to test my code along SBCL. And according to
what I have heard, this is a common choice among developers.

The main issue with CCL is that the project is almost completely abandonned.
Git activity has slowed
down to a crawl in the last two years, and none of the original maintainers
from Clozure seem to be actively working on it. It remains nonetheless a major
implementation.

ECL

Embeddable Common Lisp is a small implementation which can be used both as a
library or as a standalone program. It contains a bytecode interpreter, but
can also translate Lisp code to C to be compiled to native code.

While development is slow, improvements and bug fixes are still added on a
regular basis. Clearly an interesting project: I could see myself using ECL to
write plugins into an application able to call a C library.

ABCL

Armed Bear Common Lisp is quite different from other implementations: it
produces Java bytecode and targets the Java Virtual Machine, making it a
useful tool in Java ecosystems.

While it has not found the same success as Clojure,
ABCL is still a fully featured Common Lisp implementation which passes almost
the entire ANSI Common Lisp test suite.

Developement is slow nowadays but there are still new releases with lots of
bug fixes. Also note that two of the developers are able to provide paid
support.

CLASP

CLASP is a newcomer in the Common Lisp world (new meaning it is less than a
decade old). Developed by Christian Schafmeister for his research work, this
implementation has been used as an exemple of how alive and kicking Common
Lisp, mainly due to two
excellent
presentations.

While very promising, CLASP suffers from its young age: trying to run the last
release on my code resulted in a brutal error with now details and no
backtrace. However I have no doubt that CLASP will get a lot better: it is
actively maintained and used in production, two of the necessary ingredients
for a software to stay relevant.

GCL

GNU Common Lisp is described as the official Common Lisp implementation for
the GNU project. While it clearly does not have the popularity of other
implementations, it is still a maintained project.

Trying to use it, I quickly realized it is not fully compliant with the
standard. For example it will fail when evaluating a call to COMPILE-FILE
with the :VERBOSE key argument.

Hopefully development will continue.

CLISP

CLISP is almost as old as I am; it was the first implementation I used a long
time ago, and it still works. While it has all the usual features
(multithreading, FFI, MOP, etc.), there is no real reason to use it compared
to other implementations.

Even if it was to have any specific feature, CLISP is almost completely
abandonned. While there are has been a semblant of activity a few years ago,
active development pretty much stopped around 2012; the last release was more
than 12 years ago.

Lispworks

Moving to proprietary implementations; Lispworks has been around for more than
30 years and the company producing it still release new versions on a regular
basis.

While Lispworks supports most features you would expect from a commercial
product (native compiler, multithreading, FFI, GUI library, various graphical
tools, a Prolog implementation…), it is hampered by its licensing system.

The free “Personal Edition” limits the program size and the amount of time it
can run, making it pretty much useless for anything but evaluation. The
professional and enterprise licenses do not really make sense for anyone: you
will have to buy separate licenses for every single platform at more than a
thousand euros per license (with the enterprise version being 2-3 times more
expensive). Of course you will have to buy a maintenance contract on a yearly
basis… but it does not include technical support. It will have to be bought
with “incident packs” costing thousands of euros; because yes, paying for a
product and a maintenance contract does not mean they will fix bugs, and you
will have to pay for each of them.

I do not have anything personal against commercial software, and I strongly
support developers being paid for their work. But this kind of licensing makes
Lispworks irrelevant to everyone but those already using their proprietary
libraries.

Allegro

Allegro Common Lisp is the other well known proprietary implementation.
Developped by Franz Inc., it is apparently used by multiple organizations
including the U.S. Department of Defense.

Releases are uncommon, the last one being almost 6 years ago. But Allegro is a
mature implementation packed with features not easily replicated such as
AllegroCache,
AllegroServe, libraries for multiple
protocols and data formats, analysis tools, a concurrent garbage collector and
even an OpenGL interface.

Allegro suffers the same issue as Lispworks: the enterprise-style pricing
system is incredibly frustrating. The website advertises a hefty $599 starting
price (which at least includes technical support), but there is no mention of
what it contains. Interested developpers will have to contact Franz Inc. to
get other prices. A quick Google search will reveal rumours of enterprise
versions priced above 8000 dollars. No comment.

Conclusion

Researching Common Lisp implementations has been interesting. While it is
clear that the language is far from dead, its situation is very fragile.
Proprietary implementations are completely out of touch with the needs of most
developers, leaving us with a single open source, actively maintained, high
performance implementation: SBCL. Unless of course they are willing to deal
with the JVM to use ABCL.

It might me interesting to investigate a possible solution to keep CCL somehow
alive, with patches being merged and releases being produced. I sent a patch
very recently, let us see what can be done!