Simon Dobson (Posts about language-reference)

A programmable programming language

Simon Dobson — Fri, 10 Jul 2026 14:44:09 GMT

A programmable programming language

Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi, Eli Barzilay, Jay McCarthy, and Sam Tobin-Hochstadt. A Programmable Programming Language. Communications of the ACM 61, pp.62–71. 2018.

Lisp has been described as a "programmable programming language": the fact that Lisp code is valid Lisp data and can be manipulated as such, coupled with macros, makes it easy to construct new Lisp variants in Lisp, and to combine them with "real" Lisp in interesting ways.

Racket is a Lisp that takes this to its logical conclusion, making domain-specific sub-languages into first-class objects that can be freely interleaved within programs and can be matched to the "natural" expression of the target domain. The languages don't even have to be Lisp-like.

In the ideal world, software developers would analyze each problem in the language of its domain and then articulate solutions in matching terms.

Racket languages are formed of two parts: a reader that turns strings into properly bracketed S-expressions, and an expander that turns these expressions into "real" Racket (or some other Racket-defined language).

This flexibility adds a whole new level to Lisp programming. For example, it allows languages that don't readily translate to Lisp style to be implemented and integrated into Lisp. This may simply be for user convenience, or may have some deeper semantic structure. Racket also defines clean interfaces between languages, which is what allows them to be combined. It's a deeper version of the usual Lisp multi-paradigm approach, reaching out beyond macros working on Lisp syntax.

Lush

Simon Dobson — Thu, 30 Apr 2026 14:03:14 GMT

Lush

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?

The CONNIVER reference manual

Simon Dobson — Fri, 02 Feb 2024 12:14:30 GMT

The CONNIVER reference manual

Drew McDermott and Gerald Jay Sussman. The Conniver Reference Manual. Technical report AIM-259a. MIT AI Laboratory. 1974.

I think Conniver may have a claim to being the most influential language you've never heard of. It's a mostly forgotten Lisp variant that was a laboratory for some radically different language design ideas, and a precursor to a surprising set of features – many of which are still uncommon in the mainstream.

Conniver was intended to manage knowledge databases. This does make the report slightly hard to read in places, as there are a lot of explicit references to planning techniques wrapped-up with language mechanisms that don't really depend on them.

Conniver is (to the best of my knowledge) the first appearance of generators in a programming language. It is therefore a distant precursor of all the lazy functional languages and libraries, as well as the generators found in Python. Implementing generators within a language (rather than as a built-in part of one) requires control structures that can be exited and re-entered, and therefore needs more flexible frames for controlling executing code rather than conventional stack frames that are unwound destructively on return.

The obvious (for Lisp, anyway) next step is to make these "hairy" control structures visible within the language, to allow them to be re-arranged in interesting ways. It does this by exposing the structure of frames, consisting of:

the bound variables
the state of the ongoing computation within the frame (e.g., the program counter)
a link (the ALINK) to the frame within which free variables should be looked-up
a link (the CLINK) to the frame to which control should return on exit from the frame

This structure in turn mandates the use of spaghetti stack (or parent pointer trees) where frames are implemented using lists that can be combined in richer ways than actual, literal stacks. Thee are the underpinnings of several different common structures:

generators and continuations
closures
non-local transfers, like CATCH and THROW in Common Lisp, and therefore probably encompassing the entire condition system
functions with access to extra state (as with object methods, but in this case used as callbacks for database updates)
symbolic debuggers (not mentioned in the text)
lexical versus dynamic variable scope (not mentioned in the text, and I think it's a binary choice between one or the other depending on the ALINK, rather than accommodating lexical and "special" variable classes as Common Lisp does)

So these features are constructed in Conniver from more basic mechanisms rather than being provided built-in. I'm fascinated by what other structures one might build when every frame has two independent super-frames (one for variable lookup,one for control return) instead of one, and both can be modified independently. This is radically different to most languages in which frames are hidden and their manipulation reserved for the compiler and run-time: it's a set of ideas that re-surface at the object level in metaobject protocols.

Common Lisp: the language

Simon Dobson — Fri, 02 Feb 2024 12:10:26 GMT

Common Lisp: the language

Guy Steele. Common Lisp: The Language. Digital Press. ISBN 1-55558-041-6. 1990.

The reference manual for Common Lisp, also available online in its entirety. This is very much a reference manual and not a tutorial, but having said that it's a lot more accessible than many such documents.

It's remarkable that Common Lisp's standard has been stable for over thirty years, despite enormous advances in Lisp practices in that time. It shows the care that went into the original standardisation process, but also the effects of some detailed technical choices and (especially) the use of macros in preference to new core mechanisms.

However, it has to be said that the standard also fixed in place certain choices that now seem questionable. It's a matter of opinion, of course, but personally I think the questionable set includes at least: multiple-value returns and binds, which are unnecessary when you can return lists and destructure them and that impinge on the minimalism of the core language; and allowing symbols to be bound simultaneously to values and functions, which unnecessarily treats the two differently (and for which reason it was removed from Scheme).