It’s been a bit longer than 10 years since I started working on this project on-and-off, and it’s finally taking a shape where I feel comfortable moving things to a more stable state, and putting it on the public’s eyes.

The Lambda Garden is the result of all the little things I’ve experimented with in these last years; from programming language design, to live programming, to secure operating systems. Rather than a single tool, it’s a collection of many small projects that are now in the process of being rewritten to be stable and end-user-ready.

And I’m very excited to share that as I go through these rewrites!

A new device and OS

Out of these, the largest and most complex project in this group is Kate: a new personal computer for creative uses, modelled after portable consoles from the early 2000s era, like the Nintendo DS and Sony’s PSP. By default the specs are powered by a Raspberry Pi, with a custom OS sitting on top of a Linux kernel base: the Kate OS, a capability-secure OS with a new application format.

Kate, the device, sports a very cute design, though the mechanics of the hardware interaction and the button placement are still very much a work in progress:

The “Kate Cookie” version of the hardware — a flip-based portable computer.

It’s very much oriented towards a Do-It-Yourself culture, where I plan to share the design files and people can print and assemble the devices themselves. And once I figure out how to best get illustrations on the case in this fashion, I want to have a set of cute designs inspired by all the different project mascots. Here’s one possibility:

Kate laying down on a picnic blanket, with her cats Mocha and Caramel sleeping with her.

A new set of programming languages

In order to make the device and its operating system real (well, they are currently “real” in a prototype stage), there needs to be some quite significant work in another area: new programming languages.

One thing I’ve stumbled with a lot while working on a prototype for the Kate OS, which was originally written in TypeScript (with some, uh, very unusual type-level programming to encode some safety guarantees) was that the project very quickly grew beyond what was reasonable for a single person to keep in their head, and that goes against one of the most basic design principles in this project: one person should be able to just read the code and understand it, whether to modify or to make sure it’s doing what they expect instead of just trusting what they’re told.

At over 20k lines of (sometimes very dense) TypeScript code, spanning some virtual machines, secure IPC, key management, database management, and a few other core services, the prototype was really anything but that. Even as a high-level language, TypeScript is still unsuited for such task, regardless of whether you count the other… well, all the other safety issues it has.

For that reason I picked up the work on a very old project of mine again: Meow is a new high-level virtual machine for implementing secure (in the capability security sense) and concise applications. It follows a similar philosophy to Racket, where specific use cases are dealt with specific programming languages, which all happen to run on the same virtual machine. Just like Racket is a “language-driven” development platform, so is Meow.

The initial design was much closer to the Mu micro virtual machine, but I struggled with keeping the machine’s design that simple while still guaranteeing good interoperability and enforcing capability security, so the new design is significantly higher-level.

Meow shares its syntax with one of my previous projects you might have seen; but it also shares some of its syntax with most other languages in the Smalltalk family. Here’s a little excerpt of what it looks like, implementing part of Python’s Pickle format… a task more common in the Kate OS code than you’d probably have expected:

use meow.collection/ exposing mutable-stack;

enum op {
  binint = 0x4a,        // essentially a int32 in little endian encoding
  binunicode = 0x54,    // i32le size * u8 bytes... (UTF-8 encoded)
  list = 0x6c,          // wraps items up to MARK in a list
  mark = 0x28,          // pushes a special MARK on the stack
}

singleton mark;
struct vm(stack :: mutable-stack, input :: byte-array);

implement vm {
  def self unpickle {
    repeat with Input = self.input {
      match Input {
        <<op.binint %u8, X %i32le, ...R>> {
          self.stack push: X;
          continue with Input = R;
        }

        <<op.binunicode %u8, Size %i32le, Text %utf8:Size, ...R>> {
          self.stack push: Text;
          continue with Input = R;
        }

        <<op.mark %u8, ...R>> {
          self.stack push: mark;
          continue with Input = R;
        }

        <<op.list %u8, ...R>> {
          let Index = self.stack iterator
                        | find-last-index: (_ =:= mark)
                        | unwrap-or-panic: "Mark-using op with no mark set."
          in
          self.stack push: (self.stack slice-from: Index + 1 | as array);
          self.stack truncate-to: Index - 1;
          continue with R;
        }

        <<>> {
          break with self.stack pop!;
        }
      }
    }
  }
}

So, a very high-level language mixing functional and object-oriented concepts, featuring algebraic types and pattern matching (including matching on binary data for defining lower-level protocols). Not pictured here, but also part of the kitchen-sink are things like traits for polymorphic behaviours, capability security, effect handlers (modelled more after Common Lisp’s conditions than the algebraic ones you see in e.g.: Haskell and Ocaml nowadays. I’ll write about why it has to make that choice here eventually), and actor-based concurrency (largely modelled after E and Erlang, with some Pony influences).

Meow is much less ready for the public eyes than Kate is, however. It currently has a very bare-bones bootstrapping compiler that performs no optimisations, and lacks some very important analysis and quality of life features — for example, proper resource destruction are not yet implemented. Since the new Kate OS (and kernel drivers) code is all being rewritten in Meow, though, it’ll certainly affect the kind of features you see in it, though likely not straying too far from what you see above; a straightforward object-oriented language designed for capability security with some systems-level programming support here and there.

And, of course, since Meow is more of a “substrate virtual machine”, it’s not the only programming language in the project. There are specific languages for parsing (using PEG as a formalism), schema-based serialisation, package definitions, UI descriptions, and so on. The list of domain specific languages is actually quite large, since in the veins of VPRI’s STEPS project I’m also working with the arbitrary constraint of the entire system, and that includes the OS, drivers, and all language tooling, fitting in under 20k lines of code.

Which is… honestly a significantly easier task as I’m using Linux and Chromium as basis and not counting the either of those code footprints (●’◡’●), but I’m calling that as only half-cheating. And that’s because, unlike STEPS’ “scientific experiment on what’s possible” approach, the Lambda Garden is meant to be a practical and usable alternative for personal creative computing. And at some point you need to make some tradeoffs.