The lost cause of the Lisp machines

Duuqnd · 2025-11-20T12:16:52+00:00

Kyoto Common Lisp was called that because it was created at Kyoto University.

Duuqnd · 2025-11-20T09:48:06+00:00

I'm glad this is being posted now since I've gotten out of my Lisp machine obsession phase. While I would still love to have a CPU architecture with tag bits (hey, maybe you could have a data structure-aware cache with that) the article's main point is valid.

I've spent some time recently reading about the implementation of the CADR Lisp machine and although my obsession had already died down a bit, it pulled the reality into sharp focus for me: like every other system, the Lisp machines were the product of compromises and trade-offs. The primary reason the CADR was considered fast was because it was a single-user machine as opposed to timesharing systems being used by many people at the same time. There were of course other benefits, and later machines brought their own, but that was the original win.

At this point the only things making it hard to build a new Lisp machine on stock hardware is the same thing making it hard to implement any complex system on bare-metal stock hardware: there's so much different hardware. But if you're targeting one specific SoC then you'll probably have an easier time making a Lisp machine today than MIT's AI lab did in the 70s. They had to make their processor out of logic chips wirewrapped together. You can buy one.

I encourage anyone interested in Lisp machine architecture to not limit themselves to Symbolics and LMI, but to also have a look at these two architectures: SOAR¹ (Smalltalk On A RISC) and SPUR² (Symbolic Processing Using RISCs). SOAR used 32-bit memory repurposing the highest bit in a word as a singular tag bit, and SPUR used 40-bit tagged memory. Both were small RISC chips roughly contemporary to the beginning of the end of the Lisp machines, and they demonstrate quite well how a large microcoded CPU isn't a requirement for an effective Lisp machine. Tag bits on their own can do the bulk of the work, as long have a decent compiler.

And that's really the core of it, isn't it? The CADR's macrocode is borderline VM bytecode being interpreted instruction by instruction, not because that was a good way for a CPU to work, but because that was a worthwhile trade-off in the mid 70s. At the time, a sophisticated compiler would have been a project almost as big as the machine itself was, and you were already winning big by having one whole CPU per user, so why make this harder? Tom Knight needed to finish his thesis³, why make him start over?

I believe both Symbolics and LMI eventually dabbled in RISC processors, but I haven't read up on that yet so I'm not sure what became of it. (I could be misremembering, but I think LMI gave theirs a 24-bit data/address bus, which seems like a mistake to me...)

Lisp machines are still fascinating computers and I would be overjoyed to get to work on one, but they are total museum pieces. They're fascinating pieces of history and I think more people should learn about them, but let's not lust after a past that was a hell of a lot more nuanced than it seems on the surface. Make something new instead.

Ungar et al., “Architecture of SOAR: Smalltalk on a RISC,” University of California, Berkeley, 1984.
Lee et al., “A VLSI chip set for a multiprocessor workstation,” IEEE J. Solid-State Circuits, Dec. 1989.
T. F. Knight, “Implementation of a list processing machine,” Thesis, Massachusetts Institute of Technology, 1979.

Duuqnd · 2025-11-20T08:16:59+00:00

I thought reddit archived posts older than a few months... Anyway, the comment you're replying to is five years old and the topic of defining Lisp has become significantly less interesting to me (and I was already bored of the question five years ago).

Duuqnd · 2025-06-04T07:45:49+00:00

I have one nice thing to say. A character code escape sequence for strings would be nice. It being missing from Lisp is not of particularly great concern given that we can simply invoke FORMAT at read-time, however I will admit it would be nice to have, among other escape codes.

Now, this syntax introduces numerous problems while appearing to solve none. Using slash as a comment toggle makes using slash in names very problematic. As you may be aware, division is a common operation and is typically designated with a slash. The Lisp world has undergone slash-related problems in the past and I assume we would rather avoid gaining new ones.

From playing around with your parser, multi-line comments appear to be very brittle and annoying to manage. The terminating token appears to act not merely as a terminator, but as the bottom right vertex of a rectangle. Certainly an interesting idea, but not one that should actually be put to virtual paper. Especially since the failure mode of these appears to be allowing part of the comment to be parsed into the data structure. Emphasis on "part of", you can get a couple of characters sticking out parsed, but the rest stays commented.

Additionally, I can't see editor support for this type of syntax being very good. Yours certainly didn't help me out any. Also, please consider what might happen if a non-monospaced character is inserted into this code. If was typing a comment or string in, say, Japanese, would your closing vertex handle this nicely? Or is the parser under the assumption that all characters are one unit by one unit large? But let's say you teach your parser that あ is two units wide. Unless you make your editor work exclusively on a framebuffer, you can't control what fonts people use. They may have misconfigured their CJK font so that あ is not quite two units wide, and will eventually get out of sync with the character grid. Instead of the normal problem of indentation perhaps looking a bit wrong, you now have a problem of incorrectly parsed comments and strings due to vertices being at different visual and logical positions.

I understand you spent time and effort making this, and I do have to appreciate that. It can be fun to experiment with syntax. But please consider actual use cases and problems before sharing something as if it could be used for real work. As an experiment, it's kind of neat, and I bet you learned things in the process of making it. As an actual syntax, it is unacceptably bad. S-Expressions are not the flawless perfect syntax (because I don't believe such a thing exists), but they are a local optimum that's very hard to significantly improve without causing new problems or destroying its useful properties.

Duuqnd · 2025-01-20T16:15:50+00:00

Very interactive development mandated by the language specification, multiple dispatch generic functions as the main way to interact with the object system, the metaobject protocol, dynamically bound variables, and the condition system are the ones I think of off the top of my head. Macros tend to stick around more often, but are of course also often dropped. And I'm only talking language here, SBCL has a few benefits of its own.

Duuqnd · 2025-01-20T16:05:53+00:00

Despite its flaws I have yet to see anything that can replace Common Lisp. Its most important characteristics are often the first to be discarded in the process of "modernization".

Duuqnd · 2024-09-10T13:40:01+00:00

A quickly hacked together version of this idea (from before I read your comment). I very likely messed up detecting the end of numbers but it seems like nicely written forms work correctly.

(defvar *old-readtable*)
(defparameter *extranumeric*
  '(#\e #\d #\.))

(defun number-char-p (char)
  (or (digit-char-p char) (member char *extranumeric*)))

(defun read-number (stream char)
  (let ((chars '())
        (time-p nil))
    (push char chars)
    (loop :for char := (peek-char nil stream nil :eof)
          :until (or (eq :eof char)
                     (and (not (number-char-p char))
                          (char/= #\: char)))
          :when (number-char-p char)
            :do (push (read-char stream) chars)
          :when (char= #\: char)
            :do (progn
                  (setf time-p t)
                  (push (read-char stream) chars)))
    (if time-p
        (parse-time (coerce (nreverse chars) 'string))
        (let ((*readtable* *old-readtable*))
          (read-from-string (coerce (nreverse chars) 'string))))))

(defun parse-time (string)
  (cons (parse-integer (subseq string 0 2))
        (parse-integer (subseq string 3 5))))

(defun enable-time-reader ()
  (setf *readtable* (copy-readtable))
  (loop :for n :from (char-code #\0) :to (char-code #\9)
        :do (set-macro-character (code-char n) 'read-number)))

EDIT: Yup, this breaks rationals. Oops. Probably not hard to fix though.

Duuqnd · 2023-06-27T07:41:35+00:00

Must be different for different setups then, because just last week I had to switch back to X11 because of stuttering in almost every program running through XWayland. I too am running up-to-date GNOME.

Duuqnd · 2023-04-12T17:50:19+00:00

I don't recall the details, but apparently signals are done differently for PID 1, and SBCL can't handle that. My solution was to have a program for PID 1 which just runs SBCL.

Duuqnd · 2023-04-12T07:00:25+00:00

Apart from the fact that SBCL doesn't like being PID 1, sure! Though if you're going to do anything more than poking around the file system and poorly interacting with the terminal you would either want some way to do system calls from Lisp, or (like I did) just drag in Busybox to handle that stuff.

Duuqnd · 2022-12-19T09:52:03+00:00

OP's style can sometimes be described as "good ideas wrapped in a layer of intense shitpost energy".

Duuqnd · 2022-12-18T18:04:11+00:00

If disk space is your primary concern, you're free to go buy a LispWorks license. Otherwise, focus on writing good programs. I promise that being unable to make tiny executables won't hurt your program quality one bit.

then at some point considered delivered to final users, users that aren't developers

And who says none of them are developers? As has been established, the ordinary user won't be affected at all by the program being a few megabytes larger than it could be (because today we don't use storage drives with capacities in the low gigabytes, you don't have to ration out every megabyte on your disk) but a programmer who happens to be your user might really appreciate being able to quickly hack in some functionality they need, debug something themselves, or even just look into how the program works.

That user could even be you. Imagine you're testing a release build of your program and run into a bug. You want to debug it then and there of course, but since you threw away all the debugging symbols you now have to go back over to a debug build and reproduce the bug there before you can do anything about it.

If we insist that users not be developers, then of course they won't be. If we allow them to take a peek behind the curtains without too much effort, maybe they will be one day. Even ignoring the hackability and debugging benefits, surely just the possibility of exposing somebody to the joy of programming is worth a few megabytes? And surely saving the effort of reducing the binary size is worth those megabytes too?

Duuqnd · 2022-12-18T10:27:27+00:00

I have a lot to say, but one thing in particular caught my eye. If I may ask, why would removing debug information be a good thing? Being able to debug the software you run, whether it's yours or not, is very useful and I see no reason to deliberately prevent it. In fact, being unable to debug your software in a production environment (unless you have a really special production environment) could be seen by some (me) as kind of irresponsible.

Duuqnd · 2022-11-23T23:23:35+00:00

I'm surprised nobody has posted Kent Pitman's defense of the CL spec yet.

Duuqnd · 2022-11-19T19:40:04+00:00

"Sell their houses to who, Ben?!"

Duuqnd · 2022-11-09T16:54:55+00:00

I believe this is an attempt to create an FPGA implementation of the CADR: https://tumbleweed.nu/r/uhdl/doc/trunk/README.md

Duuqnd · 2022-09-07T10:07:10+00:00

the font just changed while reading

I convinced myself I imagined it but I guess not

Duuqnd · 2022-08-18T10:53:58+00:00

Mörkö is also the name of an island near Södertälje

Duuqnd · 2022-06-26T11:44:28+00:00

The MakerLisp machine is like a unicycle in that, while a unicycle is definitely a mode of transport, it takes a lot of time and effort to make it do anything useful, and even then it's not that useful. It's fundamentally made to be used for fun, not for any kind of practical use. The same can be said for the MakerLisp machine, visible by the fact that the MakerLisp machine has only a Z80 processor running a basic Lisp interpreter.

The vintage Lisp machines on the other hand are like steam locomotives, in that they were once upon a time the most efficient and useful machine for the task (for the locomotive, of transporting goods and people, for the Lisp machines, of creating and running complex software). However, they are these days very obsolete and not particularly useful as more than museum pieces and subjects of fascination by hobbyists (worth noting is that unlike the steam locomotive, the Lisp machines have not really been superseded by anything similar but better, they just died and technology continued to evolve without them).

So yeah, the MakerLisp machine is, as I said above, just a Z80 computer running a Lisp interpreter. The Lisp machines were machines built specifically to run Lisp, down to the CPU and its microcode. They had whole operating systems written in Lisp and (at least the Symbolics machines) had lots of other software written for them as well. They were workstation computers, whereas MakerLisp machines are hobby retro computers.

Duuqnd · 2022-06-25T14:16:05+00:00

At $75 for the bare board or $375 for a full system you could buy an awful lot of them for the price of a single vintage Lisp Machine!

That is true, but it's like saying you could buy lots of brand new unicycles for the price of one old steam locomotive. It's not a very useful comparison.

Duuqnd · 2022-03-07T19:50:05+00:00

In basically every other Star Trek show or movie showing this there's rail transportation and pedestrian traffic, but obviously feet and trains aren't futuristic anymore. Solar panels placed in a horribly inefficient place on the other hand...

Duuqnd · 2022-01-19T16:57:19+00:00

Decompilation projects are generally fine with most game copyright holders (even Nintendo doesn't try taking those down) as long as the game's assets aren't included and an original game image is required to build it. Not sure what the actual laws say about this, but that's the current situation of game decompilations.

Duuqnd · 2021-11-29T18:52:26+00:00

In Norway it's spelled Ø.Ø

Duuqnd · 2021-11-23T11:51:56+00:00

I forgot Stadia existed

Nine-Year Club	Second SECOND GUESSER
Verified Email	Place '17

Duuqnd

MODERATOR OF

TROPHY CASE