First Impressions of the Myrddin Programming Language

The language is niche enough that search engine indexing is a problem, but documentation does exist. The website has a tutorial, a library reference, and a language specification. There's also an online compiler, which seems to be the trendy™ thing to do nowadays. Jesting aside, I do really appreciate that there's an easy way to hop in and start messing with the language. I do have a some complaints, though. First, the workings of the memory model are only mentioned offhandedly in a few spots. With some effort and prior experience writing C, you can figure it out, but when I'm working with a systems programming language, I like to understand the lifetimes of my variables. This was incredibly frustrating when I wrote the assembler for chip; I was constantly dealing with strings being emptied beneath my feet. My other complaint is that the C binding interface, despite being presented as a feature on the front page, is mentioned literally nowhere in the documentation.⁵ It took some digging in the mailing lists to find the only explanation of how to use it.

There's a configuration for vim and a bundle for howl, but I don't use either, so I wrote my own major mode for GNU Emacs. It's… not great. This is the first time I've written a major mode, but it still makes for a nicer experience than writing programs in fundamental-mode. There's also support for Myrddin in Ori's fork of ctags. So… yeah. The tooling for writing Myrddin is underwhelming, but that's mostly a result of the project's size. There are other parts of the tooling that are worth remarking on, though.

In true Unix fashion, different parts of the compilation process are broken up into separate programs. 6m is the compiler (for AMD64), muse is used for symbol relocation when working with packages, and the good ol' as and ld on your system are conscripted to finish the job. This is all orchestrated by the build system for Myrddin, mbld, which I feel strikes a nice balance between utility and simplicity. Everything is defined in a bld.proj file at the root of your source tree, and the syntax is remarkably similar to the Myrddin language itself. Here's the setup for chip:

bin asm =
    asm.myr
;;

bin chip =
    main.myr
    lib sdl
;;

lib sdl =
    sdl.myr
    sdl.glue.c
;;

Targets are declared by listing the inputs that comprise them. In this case, the executable for our CHIP-8 assembler, asm, is made from the asm.myr source file, and the executable for our CHIP-8 emulator, chip is made from the main.myr source file and the sdl library, which in turn is made from sdl.myr and sdl.glue.c. There are actually quite a few target types supported by mbld (gen, in particular, got me excited, even though I didn't have anything to use it for at the time). Part of me wishes this was more general-purpose, because I'd use this as a make replacement in a heartbeat if I could.

Oh, also, if you're on Gentoo, you can install all of these from my overlay. The compiler and friends are packaged under dev-lang/myrddin.

The compiler leaves a bit to be desired, though.

jakob@Epsilon ~/Code/chip $ mbld -b asm asm.myr && ./asm
    6m asm.myr
asm.myr:52: type "char" incompatible with "byte" near Otup:(union
    `std.None
    `std.Some byte[:]
;;,byte[:][:])
    char from asm.myr:24
    byte from asm.myr:8
FAIL: 6m asm.myr

Compiler error messages are really hard to get right. They're not something I'd expect a small project like this to nail, so complaining about it feels like yelling at my houseplant for not making me dinner, but it does get old fast. Here's another one, in response to trying to invoke .len on an array instead of a slice.

jakob@Epsilon ~/Code/chip $ mbld -b asm asm.myr
    6m asm.myr
6m: typeinfo.c:363: tyoffset: Assertion `ty->type == Tystruct' failed.
CRASH: 6m asm.myr

If you ponder on this for long enough, it kind of makes sense. Y'know, the . dereferencing operator is typically used for structs, and I just introduced some code that uses that, so maybe that's the issue. But notice that we don't even have a line number in asm.myr. Not a fun thing to track down.

There are a couple of hard-to-reproduce compiler bugs as well. Take this snippet:

use std
use sdl

const main = {
    var win, r, tex
    var pixels : uint8[64 * 32]
    sdl.init(sdl.INIT_VIDEO)
    win = sdl.mkwin(("chip!\0" : byte#), sdl.WIN_POS_UNSPEC, sdl.WIN_POS_UNSPEC, 640, 480, sdl.WIN_OPENGL)
    r = sdl.mkrenderer(win, -1, sdl.RENDERER_ACCEL)
    tex = sdl.mktexture(r, sdl.PIXFMT_RGB332, sdl.TEXACCESS_STREAM, 64, 32)

    var i
    for i = 0; i < 64 * 32; i++;
        pixels[i] = (i % 256)
    ;;

    sdl.update(tex, (pixels[:] : void#), 64)
    sdl.copy(r, tex)
    sdl.present(r)

    sdl.delay(1000)

    sdl.freerenderer(r)
    sdl.freewin(win)
    sdl.quit()
}

      6m -O obj -I obj main.myr
/tmp/tmp5e0bdad78953-main.myr.s: Assembler messages:
/tmp/tmp5e0bdad78953-main.myr.s:99: Warning: 256 shortened to 0
/tmp/tmp5e0bdad78953-main.myr.s:103: Error: can't encode register '%ah' in an instruction requiring REX prefix.
/tmp/tmp5e0bdad78953-main.myr.s:125: Warning: 2048 shortened to 0
Couldn't run assembler
CRASH: 6m -O obj -I obj main.myr

It compiles fine if you replace the (i % 256) with something that doesn't involve the modulo operator. I came across a handful of issues like this when writing chip. If you do a Ctrl+F for "HACK" in main.myr, you'll see everywhere I had to get creative to avoid triggering a compiler bug. Again, though, I'm asking a lot of a small project when I complain about issues like these.

With that out of the way, I suppose it's time to see if Myrddin really is the practical, small, well defined, and easy to understand language it hopes to be. If you'd like to look at code I wrote to experiment with these features, the repository is here. I chose the name 'chip' as a reference to the bland names chosen for the emulators provided with 9front, since Myrddin seems like the kind of thing that would appeal to those folks.

It's very nice. You'll be using libstd and libbio, the buffered input/output library, mostly, but there's support for dates, HTTP, INI parsing, JSON, regular expressions, threading, and making system calls, all out of the box.

libstd provides the basic I/O functions we all expect, which work with format specifiers that are simpler than but similar to Rust's. They look like this:

std.put("{} + {} = {}\n", 2, 2, 5)

There's a unit testing library. It isn't awful, but it isn't particularly wieldy either. The example at the bottom of that page was enough to discourage me from taking a TDD-style approach with chip.

I like Myrddin a lot, and I feel it lives up to its promises of being practical and small. But at the end of the day, I don't think I'll be using it until it's matured some more – the limited architecture support and frustrating compiler bugs are enough to turn me off. I'm hopeful, though. There's work underway to write a self-hosted compiler using QBE as a backend, and we're only at release 0.3.0, so I'm certain the situation with tooling should improve in time. Maybe this is my cue to quit whining and get hacking. See ya on the mailing lists!