SICL is a Common Lisp implementation split into pieces other implementations can borrow

The argument is about reuse, not about a new Lisp

SICL is described as a new implementation of Common Lisp, and the sentence that explains the project is the one about how it is divided. It is intentionally divided into many implementation-independent modules that are written in a totally or near-totally portable way, so as to allow other implementations to incorporate these modules from SICL rather than having to maintain their own, perhaps implementation-specific versions.

That is an unusual goal for a language implementation, and it is worth reading carefully. Most Common Lisp work happens in the gaps between implementations. A reader is rewritten for every compiler, a macro expander is tied to one set of special forms, a package system is written from scratch because the last one did not fit. SICL is being built so that the parts which do not need to be tied to a compiler can be taken and used, and the parts which do can be replaced.

The dependency list makes the point concrete, because it is not a list of libraries from Quicklisp or a single compiler runtime. It is a list of around twenty separate repositories, most of them under the s-expressionists organisation, and several of them are SICL's own subsystems with names like Concrete-Syntax-Tree, Eclector, Khazern, Trucler, Clostrum, Incless and Invistra, plus supporting systems from other authors such as architecture.builder-protocol and s-expression-syntax, and alexandria from the Common Lisp project.

The audience is therefore a fairly specific one: people who implement Lisps, and people who want to assemble a Lisp rather than run one. The repository is a workspace of reusable subsystems, and the main repository holds the assembly of them.

The dependency list is the architecture in one place

The Quick Start section begins with the dependencies, and the length of that list is itself information.

There is a recent 64-bit version of SBCL required, and then the systems themselves, each named and linked to its repository: the system clonedijk from the Clonedijk repository, cluster from the Cluster repository, stealth-mixin from the Stealth-mixin repository, concrete-syntax-tree, ctype, eclector, khazern-intrinsic, trucler-reference, clostrum, incless-intrinsic, invistra/intrinsic, trivial-package-locks, alexandria, architecture.builder-protocol, s-expression-syntax, and then the systems from the Iconoclast, Common Boot, Common Macros, Parcl, Ecclesia, Predicament, Regalia, Clostrophilia and Acclimation repositories.

The naming convention gives a hint about the structure. Several entries are named with the -intrinsic suffix, which suggests the distinction between a subsystem that is tied to this implementation and a portable core, and the system names follow the same naming family as the projects they come from, so the dependency graph is a network of related projects rather than a stack of unrelated ones.

The practical point for a new user is that none of this is fetched by hand. A bash script named get-dependencies.sh does this work for you, and it is the first thing the Quick Start tells you to run after installing SBCL.

That script is also the first real friction point. A build of SICL is a build of twenty repositories, which means network access, disk space and a working Common Lisp toolchain, and it means a failure in any of them stops the whole thing. It is a research project's dependency profile rather than a product's.

Bootstrapping is a scripted procedure, and it takes minutes

The build sequence is written out step by step, and the order matters.

First the dependencies are fetched with the script, then the source is cloned:

git clone https://github.com/robert-strandh/SICL
cd SICL

Then the top-level directory has to be findable by ASDF, which is the Common Lisp system definition facility that SICL uses to locate and load its systems.

After that the boot system is compiled by loading the system, the package is changed for convenience, and an instance of the BOOT class is created. The README warns that bootstrapping may take a few minutes, and then a REPL is started.

The names of these steps carry the history of the project. The system is called sicl-new-boot, the package is sicl-new-boot, and the class is BOOT, so the bootstrap is a Lisp-level object rather than a shell script driving a compiler. That is the traditional Lisp way of building a Lisp, and the fact that a new implementation still does it this way in 2026 tells you what kind of project this is.

It also means the build produces an environment rather than a binary, and that the REPL you land in is the deliverable. For a research project that is exactly right, and for a team that wanted a packaged tool it would be a poor fit.

The repository is more documentation than code

The top level of the repository is worth reading as a description of the project's priorities, because it is mostly documents.

There is Code/, Specification/, Papers/, Talks/, FAQ.text, get-dependencies.sh, CONTRIBUTING.md and LICENSE-BSD, and the primary language recorded for the repository is TeX rather than Common Lisp, which is a direct consequence of the document weight.

The Specification/ directory is the one to look at first. The README points at it as the place for more information, and in a project whose central claim is portability, a written specification is how the portability claim gets made checkable. A module that is described only in prose can drift from the code, and a module that is specified can be implemented by someone else, which is the entire premise.

Papers/ and Talks/ suggest the project presents itself at conferences, and FAQ.text is the sort of file that tells you what a maintainer gets tired of explaining. A reader who wants to understand SICL's design decisions will get more from those than from the source tree, and the order in which to read them is the sensible order: the specification, then the FAQ, then the code.

The organisation is the same one that appears in the dependency list, and the same pattern of small focused repositories is visible inside the project, which is consistent with the claim that the pieces are meant to be used elsewhere.

The community runs on IRC, which tells you who uses it

The help section says the SICL community members are usually on various IRC channels, that there is now a dedicated channel called #sicl, and that discussion can also be found on #commonlisp and #clasp. All of these channels are on the libera.chat network, and the project links to the IRC logs for #sicl.

The presence of #clasp alongside #commonlisp and #sicl is a useful detail. CLASP is another effort in the same space, a Common Lisp that compiles to a virtual machine with C++ and Scheme underneath, and its presence in the same channel list tells you that the people who care about this kind of work are having the same conversation in the same place. SICL is part of a small community of implementors rather than a project with a user base.

The contributor path is conventional and unremarkable. If you want to contribute SICL, read CONTRIBUTING.md, and the README points to it directly.

For a project with this shape, the communication channel is part of the product's usability. There is no documentation site, no issue tracker workflow described, no forum and no chat with the maintainers. If you are going to evaluate SICL, plan on spending time in the specification and in the channel, because that is where the knowledge is.

A permissive licence, no releases, and a research posture

SICL is primarily distributed under the terms of the BSD license, with the details in the LICENSE-BSD file, and the repository's licence field records a custom licence that GitHub cannot classify, which is the usual result of a permissive licence with a project specific rider attached.

There are no published releases, and the last push was on 2026-08-30 with the repository not archived. For a project whose distribution mechanism is a source tree and an ASDF system rather than a packaged image, that is consistent, but it does mean there is no version to pin, no changelog to check and no artefact to point a colleague at. The change history is the commit log.

The posture to be aware of when evaluating this is the relationship with an existing implementation. SBCL, a recent 64-bit version of which is required to build SICL, is itself a complete Common Lisp. So SICL is not a replacement you evaluate against SBCL on features, it is an effort to build a Common Lisp whose parts are reusable, with the compiler that a new implementation needs to bootstrap itself sitting at the bottom of the dependency chain.

That framing sets the right expectation. SICL is a research and engineering project with a specification, a paper trail and a community of implementors, and the sensible first step for an interested team is to read the specification and the FAQ rather than to try to build it and compare its REPL with a production Lisp.

Editorial conclusion

SICL suits a Lisp implementation researcher, or a team building its own Common Lisp derivative that wants a tested reader, a parser and a compiler front end rather than writing them. It does not suit a team that needs a production Common Lisp this month, because bootstrapping it takes a dependency chain of around twenty repositories and a multi minute build, and because the repository's own centre of gravity is a specification rather than a shipped image. Verify first that the modules you want are the portable ones rather than the implementation-specific ones, since the whole point of the split is that some parts are portable and some are not, and read the Specification/ directory, which is where the normative decisions live.

Frequently asked questions

Official sources

1. Issues
2. README
3. robert-strandh/SICL on GitHub