Ironic Space Lisp

In order to meet some particular requirements for a separate project, I began development on a new programming language based on Lisp and Erlang. Some of the requirements were that the entire environment be pausable and serializable, and contain deep hooks and callbacks to allow the host program to dynamically control fundamental aspects of evaluation. The interpreter is currently under development in Rust.


Ironic Space Lisp Part 9

It’s been a long time since I last worked on ISL, mostly because I got distracted by other projects and languages: things like the flows project, or Clojure. Also, writing futures code in Rust is painful. Recently, async-await syntax got released on Rust nightly, which makes async code much easier to write. When I was last working on the project, I was working on a local variables feature. VM operations to allow storing and loading local variables linked to the frame stack, and later, support in the compiler.

Ironic Space Lisp Part 8


It’s been a while since I posted progress on ISL, and that is mostly my fault. Most of this time was spent making maintenance, like documentation, but also trying to get the self hosted interpreter working and self hosting. That was a challenge, and also my fault.

Ironic Space Lisp Part 7

Let’s talk about the VM internals. I’ve written a compiler for ISL, and implemented functions at the same time. This is not a mistake or an over-reach, rather a natural progression. To the VM, what is a function? The VM doesn’t have a strong concept of “functions”, or even of procedures. It has the Call and Return operations. These operations are the only way to manipulate the frame stack in a meaningful way: Call pushes an address to the frame stack, jumping to it, while Return pops an address, returning to the caller.

Ironic Space Lisp Part 6


Since last time, I did two things: switched from error_chain to failure, and refactored with the visitor pattern. They took about the same amount of time, and the refactor is much more interesting. I briefly touch on an issue I encountered with failure, but I’d rather discuss the refactor.

Ironic Space Lisp Part 5

Let’s talk about environmental bindings. I’m taking the unusual (I think) approach of sharing environment bindings code between the VM and the interpreter. Unfortunately, I wrote the environment code at the same time as the VM, and fit the code a little too closely to the requirements of the VM, and didn’t think enough about what the interpreter would require. In the process of writing the interpreter, I encountered a strong disconnect between the semantics that I wanted and the semantics I had.

Ironic Space Lisp Part 4


This update is all about parsing, and this ended up being really difficult. Not in a good way though. In my last post, I talked about using languages so difficult and alien that the difficulty clearly signified that there was something important you could learn from mastering them. I didn’t find this was the case during this phase of the project.

Ironic Space Lisp Part 3

Have you ever been working on a project and felt stupid and scared? Not in an anxious way, and not in an imposter syndrome way, but in a visceral way, like “I don’t really know what I’m doing, and I’m not sure I can do this.” Some languages are so complex and different that, although I know they’re full feature and Turing complete languages, I don’t know that I can even write whatever program I’m trying to make.

Ironic Space Lisp Part 2


Part 1

Part 2

Last time, the conceptual challenges of a the stack VM convinced me it was the wrong approach. In a normal recursive lisp interpreter, code is data, and you have a single evaluator function over every value. Follow along here.

Ironic Space Lisp Part 1


Part 1

Part 2

I recently had a new idea for a space programming game. The idea isn’t done, although the planning document is getting lengthy. Programming games need programming languages, and based on the game design, I had some pretty particular specifications for the language.