A Lisp Interpreter Implemented in Conway’s Game of Life

I include this as an application rather than an implementation technique because … well … it’s far more interesting as an example of cellular automata (CAs) than as a Lisp.

Having said that, there’s something utterly compelling in watching a CA run something this complicated. It basically implements a Lisp machine core, and watching it execute is rather like watching a real chip in action (even though the mechanisms are completely different). You can see memory being accessed. Its implementation includes lexical closures, enough to build a simple object system.

The implementation uses the VarLife system as an abstraction layer over the “raw” Conway rules. The compiled programs can be run on the Golly CA emulator.

https://www.lisp-screenshots.org/

A collection of links to Common Lisp applications, including utilities, games, and full-blown science packages and web applications. Most have links to the applications’ home pages.

https://lispcookbook.github.io/cl-cookbook/

Part tutorial and part recipe site for topics ranging from the common (syntax, the loop macro), to the advanced (packages, multi-threaded web application programming, building stand-alone binaries). It’s extremely thorough in terms of the patterns used in real Lisp code.

I think the most useful aspect is that the recipes go well beyond what’s built-in to Lisp and tackle some of the common (and not-so-common) packages: the chapter on arrays goes into a couple of linear algebra packages, for example. It also has useful chapters on development tasks like profiling and continuous integration.

Lush: my favorite small programming language

A blog post all about Lush, a small language that the authors present as a “Lisp Universal SHell” whose main features are its ability to integrate simply with underlying libraries with the interactivity of Lisp. And it’s a full Lisp, with a compiler, a macro system, an object system, and (importantly for what comes next) high-performance arrays and tensors.

Lush’s main claim to interest is that its authors include Yann LeCun, Yoshua Bengio, and the other researchers who went on to have a massive influence on the resurgences of interest in deep learning neural networks. Indeed, the first version of the Torch package, which later became PyTorch, was written in Lush. Lush’s arrays make use of a sub-language modelled on APL that leverage Lush’s ease with foreign functions to call into underlying C kernels for tensor operations.

This is a great example of how Lisp’s claim to fame as a language for doing AI has continued into the “new” AI era of deep learning models. It also shows that, if you believe that Lisp’s dynamism and flexibility are an advantage to you, there are no barriers to continuing to benefit from that even if you need to access a wider ecosystem of tools. It’d be interesting to understand the performance trade-offs in this: what is the performance of a Lush algorithm that makes extensive use of its array language, and how can this performance be maximised using higher-level language constructs of the sort Lisp encourages?

Nils Holm. Lisp from Nothing. Lulu Press. 2025.

This is a fascinating book that’s very old-school – and I mean that in the best possible way. It does exactly what it says: develops a Lisp interpreter (and then a compiler) from first principles, bootstrapped on top of an existing Lisp or Scheme against a runtime written in C, with all code provided.

It’s more than this, though. There’s a thorough discussion of the differences between dynamic and lexical variable scope (and the implications for both programming and implementation). There’s a digression into pure lambda calculus and the complexities that it introduces. There’s a basic mark/sweep garbage collector. There’s a brief history of Lisp and Lisp machines. And there’s a performance evaluation that digs into where the costs lie within the system.

Overall this is a book that every implementor should read, if only to see some other parts of the possible design space for Lisp tooling. Many applications will want to occupy a different point in that space, for example providing a richer compiler, or a richer runtime. But there’s a lot to learn from the simplicity of the choices made here.