Clasp: a Common Lisp implementation that compiles through LLVM and talks to C++

What problem Clasp solves, and who it is for

Most Common Lisp implementations live in their own world. Getting at a C++ library usually means writing a binding layer by hand, or going through CFFI against a C API that the C++ library may not expose. Clasp takes a different route: it is a Common Lisp implementation that interoperates with C++ libraries and programs directly, using LLVM for compilation to native code. The README frames the payoff as reaching preexisting libraries and programs, naming the scientific computing ecosystem as an example, and then using Lisp for rapid prototyping and incremental development on top of them.

The audience is therefore narrow but real. If you maintain a C++ codebase and want a REPL-driven workflow around it, Clasp is built for that case. If you are starting a fresh Lisp project with no C++ component, the C++ interoperation is dead weight and the build cost buys you nothing. The README also lists SLIME, ASDF, Quicklisp, CFFI, Bordeaux-Threads and Unicode as the major ecosystem components it supports, which tells you what a working setup is expected to include.

How Clasp compiles Lisp and reaches into C++

The compilation path goes through LLVM. Lisp code is compiled to native code rather than interpreted or run on a bytecode VM, and the repository layout reflects a C++ project as much as a Lisp one: src/, include/, plus a koga build tool and a repos.sexp file describing dependencies. The Dockerfile shows the toolchain in concrete terms. It installs clang19 and llvm19 alongside boost, expat, fmt, gmp, libbsd, libedit, libelf, libffi, ncurses and zlib, then builds with SBCL and ninja.

The C++ side is served by clbind, which has its own documentation page linked from the README. The README does not spell out the binding mechanism in detail, so treat clbind's documentation as the place to learn how a C++ class or function is exposed. What is clear from the build files is the shape of the dependency flow: koga populates dependencies and src/, then ninja builds and installs. The Dockerfile comment states that you need to run koga first to populate dependencies before building a container, which is the same ordering a source build follows.

Building Clasp from source: the commands and the cost

Clasp is supported on Linux, Mac OS X and FreeBSD, and the README says you should be able to build it from source on those systems, with package manager installation possibly available. The Wiki is the pointer for platform specifics. The build is not light. In parallel mode, which the README describes as :parallel-build t in config.sexp, you need more than 8 GB of RAM and a build time of 1-2 hours. Without 8 GB of RAM you can turn the parallel build off, and the README says that then runs for a day or so. It also tells you to have paging space configured.

The Dockerfile is the most explicit build recipe available. It runs koga with a fixed set of paths and options, then ninja, then ninja install:

RUN ./koga \
      --skip-sync \
      --reproducible-build \
      --build-mode=bytecode-faso \
      --llvm-config="/usr/bin/llvm-config-19" \
      --bin-path="/usr/bin/" \
      --share-path="/usr/share/clasp/" \
      --lib-path="/usr/lib/clasp/" \
      --dylib-path="/usr/lib/" \
      --build-path=build/ && \
    ninja -C build && \
    ninja -C build install

If you would rather not build at all, the README points to a container image published under the clasp-developers GitHub organisation. The Dockerfile also defines a variant that installs Quicklisp at image build time, loading quicklisp.lisp non-interactively and calling quicklisp-quickstart:install, which gives you a Lisp with a package manager already present:

clasp --non-interactive \
  --load quicklisp.lisp \
  --eval "(quicklisp-quickstart:install)" \
  --eval "(ql-util:without-prompting (ql:add-to-init-file))"

After that, the container's entrypoint is clasp, so a shell into the image drops you at the Lisp prompt. The README does not document a Windows build, and it does not describe an uninstall or rollback procedure.

Where Clasp is the wrong tool

The build requirement is the first real limitation, and it is a hard one. More than 8 GB of RAM for a parallel build, or roughly a day for a single-threaded one, is a different order of cost from installing a packaged Lisp. On a laptop with 8 GB or less, Clasp is effectively a background task, not something you rebuild while iterating on a binding.

Platform support is the second boundary. The README names Linux, Mac OS X and FreeBSD. Nothing in the README describes a Windows build, so if Windows is a target, Clasp is not the implementation to plan around.

Ecosystem coverage is the third. The README lists SLIME, ASDF, Quicklisp, CFFI, Bordeaux-Threads and Unicode as supported components, and links two of those entries to open issues in the clasp-developers repository. That phrasing suggests the list is the set of things the project considers covered, not a claim that every library on Quicklisp will load. The README does not provide a compatibility matrix, so a library that depends on implementation-specific behaviour is a question you have to answer by trying it.

Finally, the licence is not stated in the README. The repository has a licenses/ directory and the Dockerfile copies it into the build, but no licence identifier appears in the README. If your organisation requires a known licence before adoption, that is an open item, not a detail.

Clasp compared with SBCL and ECL

The nearest comparison is SBCL, which the Clasp Dockerfile itself installs as a build dependency. SBCL is a mature Common Lisp compiler that builds quickly and runs on more platforms, and for pure Lisp work there is no C++ interoperation gap to close. The difference in approach is what each implementation optimises for. SBCL compiles Lisp to native code with its own backend and its own runtime; Clasp compiles through LLVM and puts C++ interoperation at the centre of the design, with clbind as the documented interface. If your problem is Lisp performance or Lisp library coverage, SBCL is the default answer. If your problem is calling into a large existing C++ library, Clasp is addressing something SBCL does not.

ECL is the other useful reference point, because it takes a third approach: compiling to C and embedding in a host program. That gives you a small runtime and straightforward embedding, but the C++ story goes through C. Clasp's LLVM backend and clbind are aimed at C++ directly, at the cost of a much heavier build. The trade is roughly: ECL for embedding a small Lisp in a C program, Clasp for driving a large C++ program from Lisp.

Maintenance, releases and the cost of staying current

The repository is not archived, and the last push was on 2026-09-23, so the project is being worked on now. The release history shows 2.7.0 in January 2025, then 3.0.0 on 2026-06-18 and 3.0.1 on 2026-06-24. That is a long gap followed by two releases a week apart, which is worth noting if you plan around a stable branch: the 2.x line sat for about seventeen months before 3.0.0 arrived.

Upgrade cost is dominated by the build. A new release means another koga and ninja cycle, which is the same 1-2 hours and 8 GB of RAM unless you use the published container image and rebuild that instead. Because clbind is a documented interface with its own page, binding code is the part most likely to need attention across a major version bump. The README does not document a supported upgrade path between major versions, so pin a version and read RELEASE_NOTES.md before moving.

On licensing, no licence identifier is stated in the README. The repository contains a licenses/ directory and the Dockerfile copies it into the build stage, which is where to look. This article gives no legal advice; if the licence matters to you, read the files in licenses/ and, where a dependency's terms are unclear, the corresponding entries under dependencies/.

Editorial conclusion

Adopt Clasp if you already have a C++ library, such as something from scientific computing, and you want Common Lisp's incremental development on top of it, with clbind as the bridge. Do not adopt it if you need a small, fast-to-build Lisp, if your target platform is Windows, or if you need a documented licence before you can ship. Verify three things first: that your machine has more than 8 GB of RAM or that you can accept the slow non-parallel build described in the README, that your C++ dependencies are reachable from the clbind interface, and that the licence situation in the licenses/ directory is something your organisation can accept.

Frequently asked questions

Official sources

1. clasp-developers/clasp on GitHub
2. Issues
3. Project website
4. README
5. Releases