Richard Greenblatt. The Lisp Machine. Working paper 79. MIT AI Laboratory. 1974.

A description of the architecture later built and sold by LMI.

A visionary description of a machine to run Lisp at a “non-prohibitive cost” of $70,000 per system. (The web tells me that this is the equivalent of $440,000 in 2024.) A completely integrated system based on a Cons processor and using a PDP-11 as a console. A relocating, compacting, garbage collector with invisible forwarding pointers. Non-linear spaghetti stacks to support advanced programming constructs.

One of the many notable facets of this design is one of its proposals (the “frame pushdown list”) to avoid excessive conses and garbage collection overhead by maintaining lists of blocks of particular sizes. It uses this approach to manage the creation of call stack frames; modern Python implementations use this scheme throughout to avoid heap fragmentation through allocating and re-allocating blocks of different sizes. (Lisp has this feature generally, of course, with its use of fixed-size cons cells.)

It’s also fascinating to see that, even at this early stage, hardware design was being seen as an exercise in refinement to maintain software-level abstractions even as features were being pushed into hardware – while still providing optimised implementations that were invisible to the programmer.

Adam Tornhill. Lisp for the Web. Leanpub. 2015.

A short, practical guide to build a dynamic web site entirely using Common Lisp. Makes extensive use of several libraries, including the intriguingly-named hunchentoot web server (named after a never-staged musical written by Frank Zappa), the CL-WHO HTML generator, and – perhaps most interesting – the Parenscript Lisp to Javascript compiler.

One gain from using Lisp is the ability to wrap-up standard constructions like page templates as macros. Other than this, it’s hard to assess whether the gains are all that significant. One interesting point is that the whole development occurs in Lisp, so there’s no cognitive dissonance between writing the back-end and the front-end: essentially the same argument for using node.js as a back-end framework. While Parenscript isn’t a fully-featured Lisp-in-the-browser it again can benefit from macros and other features. There’s a throwaway comment about linking it to jQuery, although that isn’t demonstrated in practice: it feels intriguing, though, especially if there’s a way to represent jQuery functionality idiomatically in Lisp.

J.M. Foster. List Processing. Macdonald and Co. 1967.

A slim volume discussing list processing with reference to Lisp and to other list processing systems of the time (including some libraries embedded into Fortran).

The most fascinating part of the book is its bibliography, which references a lot of papers that have disappeared from the collective memory of computer science, but whose implications were profound.

John McCarthy. Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I. Communications of the ACM 3, pp.184–195. 1960.

The original Lisp paper from 1960, which opens:

A programming system called LISP (for LISt Processor) has been developed for the IBM 704 computer…

The paper then proceeds to lay out everything that’s since been built on: the basic constructs, the use of cons cells (pairs) as a data representation, the world’s first garbage collection algorithm, an equational semantics, and ideas for interpretation and compilation. It’s awesome, and humbling to read it and realise its age and the vision of computing it developed.

(Despite this paper being labelled Part I, incidentally, there isn’t a part II.)

Peter Norvig. Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp. Morgan Kaufmann. 1992.

An absolute classic of both AI and Lisp, and really two books in one. The applications presented cover the entire range of “classic” AI up to the late 90s: expert systems, logic programming, symbolic mathematics, knowledge representation, constraint programming, game search, syntax-driven natural language processing, and more.

It uses Lisp as the programming vehicle, and doesn’t shy-away from depth, dealing with the effects of garbage collection (and how to program effectively in its presence), the effects of different representations, low-level optimisation and disassembly, and all the approaches one needs to use Lisp in real, scalable practice.