On Lisp

The pitch in one line

On Lisp makes one big claim: the way to use Lisp well is to build a custom language up toward your program, and then write the program in that custom language. Graham calls this “bottom-up programming,” and the whole book is an extended proof — about 400 pages of techniques, examples, and embedded-language showpieces — that this approach is what separates fluent Lisp users from people who happen to write code in Lisp.

The phrase Graham keeps returning to is John Foderaro’s, quoted on page one: “Lisp is a programmable programming language.” The book is, in effect, a manual for that programmability.

This is not a beginner book. Graham assumes you’ve already met Common Lisp, can write a recursive function without flipping back to a reference, and want to know what the language can do once you stop treating it as a slightly weirder Python. If you’re new to Lisp, read Practical Common Lisp first and come back when the parentheses are no longer the obstacle.

What “bottom-up” actually means

The first few chapters are framed as review — functions, scope, closures, functional style — but the part that sets up everything that follows is chapter 4, on utility functions.

Graham’s pitch is that any non-trivial Lisp program will accumulate a small library of helpers — predicates, mappers, list operators — that aren’t quite worth releasing as a package but absolutely belong in your toolkit. He argues these are capital expenditure: each one costs a few minutes to define and a few minutes to remember, and pays back every time you stop writing the same destructured loop for the third time. Many of Common Lisp’s built-in functions, he notes, started life as one programmer’s utility.

So far this is just “extract methods.” What makes it bottom-up is the next move: once your program has accumulated enough utilities, it stops looking like a program in Common Lisp and starts looking like a program in a custom language whose vocabulary is exactly the operations your problem requires. That custom language is the one you should be reading — and writing — your code in. Lisp’s bottom layer is just the fabric you sewed it out of.

This is the cleanest articulation of domain-specific-language thinking we’ve found anywhere. It’s worth reading even if you never write another line of Lisp.

Macros: the part you came for

Roughly a third of the book is about macros. This is the centrepiece, and it’s the reason On Lisp still gets recommended in 2026. Chapters 7 through 11 walk through the mechanics, the design taste, and the pitfalls.

The mechanics first. A macro in Lisp doesn’t return a value; it returns code, which the system then evaluates. Because Lisp programs are just lists, macros pick apart their input the way functions pick apart numbers, and stitch new lists back together. Graham gives the standard worked examples — setf, when-bind, a hand-rolled do — and then turns to the part the rest of the literature mostly skips: how to write macros that are correct, not just clever.

The two chapters on pitfalls are the strongest in the book.

The chapter on variable capture is the clearest treatment of the problem we know of. Capture is what happens when a macro’s expansion accidentally introduces a binding (or refers to one) that collides with the user’s code. Graham distinguishes argument capture — where the macro’s parameter name shadows a local variable in the user’s expression — from free symbol capture — where the macro’s expansion references a name that the user happens to have rebound. He names exactly where each can occur, and walks through the standard defences: rename, evaluate early, gensym, package isolation. He doesn’t hand you gensym as a magic spell. He shows you why every other defence is partial and why gensym ends up being the load-bearing one.

The chapter on order and number of evaluations is a similarly clear-eyed treatment of the other class of macro bugs: arguments that get evaluated zero times when you wanted one, or three times when you wanted one. Both chapters are genuinely useful even if you spend your days writing Rust or TypeScript — every language with metaprogramming has its own version of these problems, and Graham’s framing transfers cleanly.

The big claim Graham defends across these chapters is that macros are not interchangeable with functions. Most of the time you should reach for a function. But there are several things only a macro can do — bind a variable, conditionally evaluate, transform inputs before evaluation, run code at compile time, save the function-call overhead — and those are the moments where the language is supposed to bend.

Embedded languages: the showpiece chapters

The last third of the book is where Graham cashes in the bottom-up promise. He builds, inside Common Lisp, a series of progressively more ambitious embedded languages: a pattern-matching destructurer, a query compiler over an in-memory database, a continuation-passing macro layer that mimics Scheme’s call/cc, a multiple-process simulation, a nondeterministic search facility with choose/fail, an ATN parser for a small grammar of English, and finally a Prolog interpreter and a Prolog compiler.

The Prolog chapter is the bravura performance. In a couple of dozen pages, Graham builds a working Prolog — facts, rules, depth-first search with backtracking, cuts, arithmetic, embedded Lisp expressions — and then upgrades it from interpreter to compiler so that queries get analysed at compile time rather than walked at runtime. The point isn’t that you’d use this Prolog for serious work. The point is that the distance from “I want a logic-programming sublanguage” to “I have a logic-programming sublanguage” turns out to be a few hundred lines of macros.

This is what the bottom-up pitch is really selling. The cost of inventing a small language for your problem, in Lisp, is shockingly low. No parser, no separate compiler, no plumbing to integrate it with the host. The new language inherits everything from Lisp because it is Lisp, lightly reshaped.

The CLOS chapter at the end belongs to the same tradition. Graham first builds a tiny object system in plain Lisp — properties, message dispatch, inheritance — and then switches to real CLOS to introduce generic functions, multimethods, and the auxiliary method protocols (:before, :after, :around). The framing is consistent: CLOS is itself an embedded language, written in Lisp, and the only difference between it and the toy system you can write in an afternoon is engineering thoroughness.

The weak parts

Not every chapter has aged equally well, and the book is honest enough about some of its limits that we’ll be honest about the rest.

The continuations chapter is a heroic act, but it’s a Common Lisp workaround for the absence of a feature Scheme has natively. Graham’s macros let you write code that looks like it has call/cc and produces something that vaguely behaves like Scheme. Reading it is intellectually exciting — the macro pyrotechnics are the most ambitious in the book — but the result is a curiosity rather than a tool you’d reach for in production. If you actually want continuations, you use Scheme.

The multiple-processes chapter admits its own status. Graham calls the result a “less-than-rapid prototype” and notes that the processes are slow compared to real OS-level concurrency. The chapter is included to demonstrate that you can prototype concurrency primitives in Lisp, not because the result is something you’d ship. Today this lesson is better learned by reading about Erlang or Go.

The ATN parser chapter is the most dated. Augmented transition networks were a 1970s formalism for parsing limited subsets of natural English, and the whole approach has been swept aside by statistical and now neural methods. The chapter is still interesting as another demonstration of how cheaply you can compile an embedded formalism into Lisp, but the formalism itself is a museum piece. Anyone reading the chapter expecting natural-language insights will close it more puzzled than they opened it.

More broadly, the book oversells extensibility as an unalloyed good. Graham makes the case for bottom-up so well that he barely makes the case against it. If every team builds its own custom language to fit its own problem, every new hire has to learn that language, and every utility your codebase invents is a utility nobody else will recognise. Lisp shops have always struggled with this onboarding tax, and the book mostly waves the problem away. The dense-versus-readable trade-off appears briefly — Graham comes down firmly on the side of dense — but the position is asserted rather than argued.

The book is also relentlessly enthusiastic about its subject. There’s almost no point at which Graham says “and here is where Lisp’s approach is the wrong one.” Lisp programmers reading On Lisp in 1993 may not have needed that section. Anyone reading it in 2026, with three decades of language-design hindsight, will notice its absence.

What’s missing

A reader who finishes On Lisp and wants to actually ship something will need to fill in three things the book deliberately leaves out.

First, modern Common Lisp tooling and ecosystem. Quicklisp, ASDF, SBCL-specific optimisations, FFI patterns, deployment, image-saving versus compile-to-binary trade-offs, the role of CFFI and cl-autowrap — none of this exists in the book, because most of it postdates 1993. You’ll need a separate set of resources for any of it.

Second, testing as a discipline. Graham talks about interactive testing at the REPL, which is genuinely a strength of the language, but he doesn’t address how you keep regressions from sneaking in over months of development. There’s no test-framework story, no property-based testing, no CI. The interactive style he describes works well for one programmer with the whole program in their head, and decays sharply at team scale.

Third, the parts of metaprogramming that aren’t macros. The book is strongest on syntactic transformation at compile time. It’s quieter on the runtime reflective machinery — the metaobject protocol, dynamic class redefinition, image-based development — that Smalltalk and CLOS pioneered and that most modern languages still haven’t caught up with. For that, The Art of the Metaobject Protocol is the companion read.

Who should read it

Read On Lisp if any of these are true. You write Lisp seriously. You write a language with macros — Clojure, Racket, Elixir, Julia, Rust’s macro system. You’ve ever thought about building a DSL and wondered how far it could be pushed. You teach programming and want a clear treatment of variable capture to point students at.

Skip it if you’re new to Lisp — start with Practical Common Lisp. Skip it if what you actually need is a tour of CLOS — The Art of the Metaobject Protocol is better aimed at that. And skip it if you already know macros cold and want to argue about hygiene. The book’s hygiene story is a Common Lisp story (gensym, packages) and won’t move you toward Scheme’s hygienic macro system or Racket’s syntax-rules tradition.

For everyone else, especially the AI-curious developer who’s spent the last few years writing prompts and wiring tools together, the book is a useful reframing. A surprising amount of what we do when we orchestrate LLMs is, structurally, embedded-language design. We invent a small vocabulary that fits a problem and try to get the host language out of the way. On Lisp is the cleanest argument we know of for why that work is real engineering — not a step down from “real” programming. The fact that the host language in 1993 happened to be Common Lisp is a historical accident. The thinking transfers.