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.
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.
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.
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.
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.
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.
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.
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.
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.
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.