Simon Dobson

Unexpected (to me) behaviour in Lisp sub-typing

Simon Dobson — Fri, 07 Aug 2026 09:27:05 GMT

Unexpected (to me) behaviour in Lisp sub-typing

I just encountered some unexpected behaviour in how Common Lisp (or at least SBCL) handles array sub-typing.

Suppose you have a structure declaration like this:

  (defstruct A
    (a #1A() :type (simple-array integer)))

We can create instances of this struct by providing an initial value, and it will be type-checked.

  (make-a :a #1A(1 2 3))

#S(A :A #(1 2 3))

We can also omit the argument and get the default specified in the declaration:

  (make-a)

#S(A :A #())

So far so good. But suppose we now specialise the simple-array type against a type such as (unsigned-byte 16) (the type of unsigned 16-bit integers).

  (defstruct B
    (b #1A() :type (simple-array (unsigned-byte 16))))

  (make-b :b #1A(1 2 3))

This generates an error, as does using the default value.

Why is this? I eventually tracked the problem down to the fact that the expression #1A() is given type (simple-vector 0) while the expression #1A(1 2 3) is given type (simple-vector 3), and neither of these are sub-types of (simple-array (unsigned-byte 16)):

  (type-of #1A())

(SIMPLE-VECTOR 0)

  (type-of #1A(1 2 3))

(SIMPLE-VECTOR 3)

(typep #1A(1 2 3) '(simple-vector 3))

(typep #1A(1 2 3) '(simple-array (unsigned-byte 16)))

NIL

So the typing works for integer (and indeed for number and float) but not for the constrained types like (unsigned-byte 16) – although it does work for unsigned-byte (with no width).

Interestingly the tests fail for empty arrays as well:

  (typep #1A() '(simple-array (unsigned-byte 16)))

NIL

I assume that the behaviour is because the compiler is at liberty to optimise the storage of arrays with specific types, and doing so makes it awkward to compare against types like simple-vector that don't contain their element type. This would also explain why the check succeeds for types like integer, whose values are stored boxed and so can represented uniformly.

There's a simple way around this, of course, once you know what the problem is: make the type of the value explicit rather than relying on the reader macro. For example:

  (defstruct C
    (c (make-array '(0) :element-type '(unsigned-byte 16)) :type (simple-array (unsigned-byte 16))))

  (make-c)

#S(C :C #())

and also:

  (make-c :c (make-array '(3) :element-type '(unsigned-byte 16) :initial-contents (alexandria:iota 3)))

#S(C :C #(0 1 2))

I can't find this behaviour detailed in the manuals (or anywhere else) though. However, it seems to be related to the upgraded array element type. When an array is created, the implementation is allowed to use a different type to the one specified in its representation, which must be a supertype of the type requested. For types like integer and unsigned-byte this is t, the top type in the lattice:

  (upgraded-array-element-type 'unsigned-byte)

But for the "constrained" types the upgraded type is the type itself:

  (upgraded-array-element-type '(unsigned-byte 16))

(UNSIGNED-BYTE 16)

This suggests to me that the compiler (SBCL) is indeed optimising the representation and then also performing more detailed type-checking for elements.

A road to Lisp -- Which Lisp?

Simon Dobson — Fri, 07 Aug 2026 08:59:43 GMT

A road to Lisp: Which Lisp?

A Road to Lisp: Which Lisp

A blog post reviewing four dialects of Lisp that a beginner wanting to start with Lisp can choose: Common Lisp, Clojure, Racket, and ELisp. The author, Elia Scotto, interestingly doesn't include Scheme, although he does present Racket as a Scheme dialect (which of course it is).

Does the choice too make initially matter?

Dialect matters, but not as much as a beginner might think. Learning Lisp is about learning a new type of programming. A new way of thinking about problems using code. You will learn the fundamental concepts with any dialect. Then, once you have learned one, it will be relatively easy to switch to another.

I think most Lisp devotees would agree with the sentiment that it's about a new relationship with code; I'm not totally convinced that Racket is a good place to start, given that it's essentially several languages; and ELisp only makes sense if you are already a devoted Emacs user, otherwise the learning curve will be nearly vertical.

Scotto's conclusion is that Clojure is the safest first choice, giving you a modern syntax and full-stack environment with access to all the Java libraries, while Common Lisp gives you fast native compilation within a large, stable, and rock-solid ecosystem, and Racket is a good basis for language research.

For my own part I came to Scheme first when I was an undergraduate, then picked up ELisp when I started using Emacs, and then learned Common Lisp when I started wanting to write significant code – and there I've stayed with the latter two, quite happily. It's certainly the case that it's been easy to move between these dialects, modulo some differences that are purely syntactic. And it's certainly true that Lisp changed my relationship to code in a deep and persistent way.

Antwerp

Simon Dobson — Sat, 01 Aug 2026 00:00:00 GMT

Michael Pye (2021)

Antwerp is, to the modern eye, a strange choice for an urban biography. But it's a place that can make a fair claim to having invented a lot of the modern world, notably the financialisation of trade and especially of art: the first place where one bought paintings from dealers rather than commissioning them from the studios. A place that tried valiantly to separate trade from religion, to protect its minorities and resist anti-Protestant edicts while still being rules from Spain, and to ride-out the waves of regulation and repression that washed around it. It was a bold experiment in trying to re-become a city-state, at a time when that simply wasn't possible any more.

It's impossible to read this book and not feel its author's debt to Barbara Tuchman, both in the general style of writing and in the sharp eye for personal detail. There are a couple of quite detailed biographies, of an architect and a printer/publisher, each of which is both engaging gossipy and carefully chosen to show the changes that each man was essential in bringing in. In that way it's a very personal book that seeks to illustrate the history of the city by the histories of individuals, gleaned from a formidable amount of primary research: Pye seems to have read every letter, book, and bill relating to the period.

I don't think it quite succeeds, despite the great writing and scholarship: the city's history seems confused and lost amid the detail, it's hard to follow the timeline and understand the sweep of the politics and the events shaping it. But it's still a superb read, packed full of anecdotes and the seeds or modernity.

3/5. Finished Saturday 1 August, 2026.

(Originally published on Goodreads.)

Hothouse Earth: An Inhabitant's Guide

Simon Dobson — Sat, 18 Jul 2026 00:00:00 GMT

Bill McGuire

A horror story, with the additional horror of being entirely backed by science.

I'm writing during the 2026 summer heatwaves in the UK, and this was really not the time to be reading this book. It lays bare the best estimates for changes caused by global heating to everything from diseases and food production to sea levels and increased earthquakes (caused by the land rebounding after the compression caused by ice is removed). The world envisaged is not entirely unlivable, but that's only a slight comfort given the tribulations to come.

Had we acted on global heating at the time of the Stern review of 2006 it might have been possible to avoid the worst at a reasonable economic cost. (McGuire, interestingly, doesn't mention Stern, whose conclusions have often been criticised for being understated in both risks and costs.) We're now in a position where we have to make much more expensive and difficult carbon reductions to avoid terrible harms, while also having to incur massive costs to mitigate the harms that are already baked-in to the climate system.

It's not a book that's entirely without hope: the last chapter paints two pictures of London later in the century under different emission reduction scenarios that highlight that a warmer world would be liveable (and even pleasant) – but only after actions that frankly seem beyond us as a civilisation. McGuire points to the hypocrisy of world leaders as the COP26 conference, promising cuts while permitting more drilling: As I'm writing, more drilling permits are being issued by the new UK administration, and AI data centres are being proposed that will require local gas-fired power stations exceeding the current generation capacity of the entire UK electricity grid. It seems we still have to grasp the scale of changes required, with those changes growing the longer we wait.

5/5. Finished Saturday 18 July, 2026.

(Originally published on Goodreads.)

Beautiful Racket: An introduction to language-oriented programming using Racket

Simon Dobson — Tue, 14 Jul 2026 07:07:51 GMT

Beautiful Racket: An introduction to language-oriented programming using Racket

Matthew Butterick. Beautiful Racket: An Introduction to Language-Oriented Programming Using Racket. 2024.

Racket positions itself as a "programmable programming language" – more so than Lisp's usual claim to this title – which makes it attractive for exploring multi-paradigm and multi-language programming.

Racket's main claim to a niche is allowing a programmer to define new domain-specific languages (DSLs), not necessarily Lisp-like, that can be combined together to let a program be expressed in the "most appropriate" form for the problem. This books is structured around exactly this idea, defining a succession of languages of increasing sophistication to demonstrate Racket's capabilities. Each language has a "reader" to convert strings into Lisp S-expressions and an "expander" to translate these forms into Racket (or another Racket-defined language). The examples include a simple stack-based calculator, an embedded JSON parser, and a Basic interpreter that exercises the power of a full parser.

The description of Racket itself is very thorough, to the extent that this book could be treated as a language definition itself, complementing the article about it. Certainly it provides the most accessible way to learn the language and explore what it means to explore "language-oriented" programming.

It's possible to define DSLs in Common Lisp or Scheme without Racket's extra functionality, and in many cases that will be sufficient – especially when the DSL is a Lisp itself. But there will certainly be applications for which Racket is absolutely the right tool.

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.

Stasiland: Stories from Behind the Berlin Wall

Simon Dobson — Mon, 22 Jun 2026 00:00:00 GMT

Anna Funder (2003)

A view of East Germany by a semi-outsider, an Australian living in the East. Perhaps this gives a better perspective.

The Stasi come across in this book as the most dedicated and efficient secret police force imaginable. They want to known everything – to the extent of imprisoning one of their own agents for not reporting something that he knew would get him into trouble – and co-opted a large fraction of the East German population to report on their friends and families, even when those reports served no purpose other than simply to be reported.

It's surprising how many former Stasi men (and they were all men) Funder managed to persuade to speak to her, and how open they were about some of the frankly amazing technology and tradecraft they employed. She is clearly a skilled journalist and a good listener, perhaps aided by her outsider status and fluent German.

There are some comic incidents, as one would expect, notably the Stasi man who steals a cheap trinket when he retires and is then persistently investigated even though no-one cares about the object itself. And then when Germany re-unifies he is investigated again by the authorities: once for the theft (which now concerns reunified Germany's state property) and then again for lying about the theft. Kafka would have approved.

But the main story is one of persecution, where a single mistake – the details of which may never be apparent – can blight someone's entire life. It can make them unemployable, with the additional twist that they can't actually be unemployed because that is considered a Western phenomenon that the state has declared does not exist in East Germany. The Party invents and publicises a new dance that's designed to eliminate all contact between dancers so as to avoid temptation. It's hard to imagine the level of false consciousness living under such a system required of everyone – and even harder to understand that some still yearn for its barren certainties.

4/5. Finished Monday 22 June, 2026.

(Originally published on Goodreads.)

The Lisp curse

Simon Dobson — Thu, 18 Jun 2026 09:07:24 GMT

The Lisp curse

https://www.winestockwebdesign.com/Essays/Lisp_Curse.html

The power of Lisp is its own worst enemy.

An interesting essay on the "Lisp curse", the idea that Lisp's power can sometimes be a disadvantage for developers. The core idea expressed as a question: how hard is it to add object-oriented features to a language? In the C world it's happened twice, giving rise to C++ and Objective-C, an no-one would even think about defining their own. In the Lisp world, by contrast, building that style of object-oriented extension is a weekend's work (assuming we didn't already have CLOS, which is in many ways superior anyway). The point is that it's relatively easy to build even complex features as libraries, meaning there's less reason to standardise, and this leads to a proliferation of mutually incompatible designs that solve 80% of the problem – but all a different 80%. This then makes interoperability difficult.

In fact the essay goes farther, to argue that the sorts of people who write Lisp tend not to be the sorts of people of work well in the political and compromise-driven world of standardisation. I'm not sure how true that is, given the stability of the Common Lisp standard itself since its adoption in 1994, but it's an interesting reflection on how increased language expressiveness need not automatically be a strength.

(Some of the links in the article are now broken, or point to what looks like an AI link farm.)

Programming algorithms in Lisp

Simon Dobson — Sat, 13 Jun 2026 11:15:03 GMT

Programming algorithms in Lisp

Vsevolod Domkin. Programming Algorithms in Lisp. Apress. 2021.

This is exactly what it sounds like: an algorithms textbook that uses Lisp as its implementation language. It has the strengths and weaknesses of all such textbooks: it shows programmers, especially new programmers, how to write algorithms that are both correct and efficient, and the places where incorrectness and inefficiency will hide; and in doing this it tempts them to write algorithms that are already implemented in libraries, when they should really seek out and re-use the already-developed and -debugged code.

But of course there are always new algorithms that don't have an existing library and therefore need to be written from scratch. This book is excellent preparation for that. It would give a new-ish programmer the confidence to tackle a challenging algorithm design and implementation job. It ranges well away from the common algorithms, to cover things like approximation and (especially importantly) parallelism and lock-free data structures, and I can imagine it providing templates that could be used as starting points for a huge range of new algorithms. Just remember not to re-invent the wheel.

Modern Common Lisp with FSet

Simon Dobson — Fri, 12 Jun 2026 08:56:40 GMT

Modern Common Lisp with FSet

https://fset.common-lisp.dev/Modern-CL/Top_html/index.html

A book-length description of a library, FSet, that provides functional collections for Lisp. By "functional collections" the author means collections – sets, trees, maps, and others – where update always produces a new collection rather than mutating the original collection in place. This is an attractive property for a language, and one that's hard to do efficiently. As with Purely functional data structures, it provides a change of emphasis that makes for more referentially transparent code.

The book contains a lot of discussion about the library's rationale and design, which makes it useful as a reference for others designing large libraries (or new languages, which of course in Lisp can mean much the same thing). There's an equally important discussion about what's not provided (for example lazy collections) which is really interesting by giving an example of when to stop with a codebase that could otherwise probably grow indefinitely.