path: root/posts/first-impressions-of-the-myrddin-programming-language.org

#+TITLE: First Impressions of the Myrddin Programming Language
#+DATE: <2020-01-05 Sun 18:38>
#+TAGS: opinion programming myrddin

It's been [[http://jakob.space/blog/first-impressions-of-the-rust-programming-language.html][over a year]] since I last wrote about contenders for the throne that C
currently sits upon, so I'll spare you the prosy introduction and cut to the
chase. I'd like to share some thoughts on my recent foray into a little
programming language I came across while browsing [[https://lobste.rs/][lobste.rs]] some years ago:
[[https://myrlang.org/][Myrddin]], the pet project of [[https://eigenstate.org/][Ori Bernstein]]. From the language specification,
"Myrddin is designed to be a simple programming language. It is designed to
provide the programmer with predictable behavior and a pragmatic set of
semantics, providing the benefits of strong type checking, generics, type
inference, and modern features with a high cost-benefit ratio. Myrddin is not a
language designed to explore the forefront of type theory or compiler
technology. Its focus is on being a practical, small, well defined, and easy to
understand language for work that needs to be close to the hardware. Myrddin is
influenced strongly by C and ML, with ideas from too many other places to name."
The front page of the website specifically states that "[i]t aims to fit into a
similar niche as C, but with fewer bullets in your feet." I see these
descriptions and the cat-v-inspired stylesheets as a warning to those who don't
appreciate a spartan attitude towards software development.[fn:2] Fortunately,
I'm not one of those people.

Like last time, I'll be getting my hands dirty using the language to implement
something nontrivial. There aren't many other applications written in Myrddin;
the [[https://eigenstate.org/software/ircmyr][irc.myr]] IRC client is the only real example I was able to find.[fn:3] It
seems most of the work has gone towards developing libraries.

It took a restless night for me to come up with a project for my exploration. I
took a peek at the [[https://myrlang.org/wishlist][wishlist]], but nothing on it stood out to me. My choices were
restricted somewhat by the limited architecture support: I wanted to work on a
lightweight [[https://en.wikipedia.org/wiki/Imageboard#Danbooru-style_boards][Booru]] engine to use as a self-hosted tagged image gallery, but my
"server"[fn:1] is ARMv6, so I wouldn't have been able to use it myself. Oh well.
The next language I plan to write about uses LLVM as a backend, so I'll have my
opportunity then. Some of the other ideas I toyed with were a text editor and a
Lisp interpreter[fn:5], but I settled on hacking together a CHIP-8 emulator.
That demands some sort of graphical output, so it should be a good opportunity
to demonstrate the C binding support. There's plenty of room to go above the
bare-minimum for features, too, like implementing an assembler, debugger, or
JIT. (I only ended up doing the first of those). Furthermore, it would be (to my
knowledge) the first graphical application writen in Myrddin, and I figure that
a CHIP-8 emulator of my own would be good to have, because if I ever decide to
write a "toy" compiler, CHIP-8 machine code would make for a fun target. But
before we can start writing an emulator, though, we've got to read the docs.

* Documentation

The language is niche enough that search engine indexing is a problem, but
documentation does exist. The website has a [[https://myrlang.org/tutorial][tutorial]], a [[https://myrlang.org/doc/index.html][library reference]], and a
[[https://myrlang.org/spec.html][language specification]]. There's also an [[https://myrlang.org/playground][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.[fn:4] It took some digging in the
mailing lists to find the [[https://eigenstate.org/archive/myrddin-dev/2015-Oct/0000002.html][only explanation]] of how to use it.

* Tooling

There's a [[https://git.eigenstate.org/ori/vim-myr.git/][configuration for vim]] and a [[https://github.com/refi64/howl-myr][bundle for howl]], but I don't use either,
so I wrote my own [[https://git.sr.ht/~jakob/myrddin-mode][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
[[https://git.eigenstate.org/ori/ctags-myr.git/][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.

* Build System

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, [[https://myrlang.org/mbld/][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:

#+BEGIN_SRC myrddin
bin asm =
	asm.myr
;;

bin chip =
	main.myr
	lib sdl
;;

lib sdl =
	sdl.myr
	sdl.glue.c
;;
#+END_SRC

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 [[https://git.sr.ht/~jakob/zerodaysfordays][overlay]]. The
compiler and friends are packaged under =dev-lang/myrddin=.

The compiler leaves a bit to be desired, though.

#+BEGIN_SRC prog
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
#+END_SRC

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.

#+BEGIN_SRC prog
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
#+END_SRC

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:

#+BEGIN_SRC myrddin
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()
}
#+END_SRC

#+BEGIN_SRC prog
      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
#+END_SRC

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 [[https://git.sr.ht/~jakob/chip/tree/master/main.myr][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.

* Language Features

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 [[https://git.sr.ht/~jakob/chip][here]]. I chose the name 'chip' as a reference to the bland names
chosen for the [[http://man.9front.org/1/nintendo][emulators provided with 9front]], since Myrddin seems like the kind
of thing that would appeal to those folks.

** Syntax

I dig it! The parser deals with logical lines, so semicolons aren't necessary,
but can be used in place of a newline if desired. It ends up feeling a bit like
Go. The only control flow constructs in Myrddin are =if/elif/else=, =while=, and
=for=. I suppose there's =goto= as well, but I haven't had a good reason to use that
yet. =elif= is a cute nod to (presumably) Python. The convenience I'm most
thankful for is the support for tuple destructuring.

#+BEGIN_SRC myrddin
var a, b
(a, b) = (1, 2)
std.put("a: {}, b: {}\n", a, b)
#+END_SRC

#+BEGIN_EXPORT html
<div class="mastodon">
    <iframe height="180" src="https://icosahedron.website/@technomancy/103359833068002215/embed"></iframe>
</div>
#+END_EXPORT

** Scoping

Right off the bat, we're doing better than C. Declarations can appear in any
order, and can be used at any point where they're in scope. In other words,
function prototypes are unnecessary.

Variable shadowing is half-way there. This works:

#+BEGIN_SRC myrddin
var a = 1
if true
	var a = 2
;;
std.put("{}\n", a) // Prints "1".
#+END_SRC

But with this, the compiler throws a fit about "pattern shadows variable
declared near a:int".

#+BEGIN_SRC myrddin
var a = 1
match 1
| a: std.put("{}", a)
;;
std.put("{}", a)
#+END_SRC

** Closures

Yep, there's support for lexical closures. It's rockin'. What's interesting is
that there isn't a special syntax for declaring functions. Instead, you assign
function literals to symbols.

A minor point, but returning early from a function in Common Lisp is enough of a
pain in the rear that I'd like to point it out here. Myrddin supports multiple
points of exit from a function.

#+BEGIN_SRC myrddin
const factorial = {n
        if n < 1
                -> 1
        ;;
        -> n * factorial(n - 1)
}
#+END_SRC

Of course =if= being an expression in Common Lisp makes =factorial= trivial to
implement without any early-return constructs, but you get the point.

** Type System

One difference between Myrddin and some other languages with type inference like
Rust is that Myrddin doesn't require that arguments have a type specifier. This
is valid Myrddin code:

#+BEGIN_SRC myrddin
use std

const factorial = {n
	if n < 1
		-> 1
	;;
	-> n * factorial(n - 1)
}

const main = {
	std.put("{}! = {}\n", n, factorial(n))
}
#+END_SRC

It does start to fall apart if you have unused functions that are more
complicated than the =factorial= example, but for the most part, you can get away
without giving any type specifiers, which is nice.

There's also support for algebraic data types (with all of your favorites in
=std=, like =std.result=) and pattern matching, which is capable of descending into
the structure of practically any type. Even "pointer chasing," or matching on
the value referenced by a pointer. There's a neat syntax for referring to ADT
variants with backticks, which I think does wonders for readability. The only
beef I have is that I was yearning for an =if let=-type construct the whole time,
but that's a minor point.

Aside from that, I don't have many comments about the type system. I appreciate
the support for fixed-width integer types and tuples, and I'm glad that there's
support for generics (with traits, =impl=, et al.), even if it isn't something I
used extensively when writing chip.

After working with Rust, being given access to raw pointers in Myrddin feels
like getting a BB gun for Christmas. They're a bit funky, though. You have to go
out of your way to do pointer arithmetic, which is probably a good thing.

The syntax for array literals is pretty neat, too. You can selectively
initialize certain indices like =x = [0: 1, 73: 2]=.

** Package System

[[https://eigenstate.org/notes/myrmodules][The Myrddin module system is simple and easy to understand. There simply isn't
much to it.]] Really, though, they're little more than a =pkg= clause listing all of
the declarations to be exported. Here's the =pkg= for my SDL2 wrapper:

#+BEGIN_SRC myrddin
pkg sdl =
	const INIT_VIDEO : uint32 = 32

	extern const init : (flags : uint32 -> int)
	extern const quit : (-> void)

	type win = void#

	const WIN_POS_UNSPEC : int = 536805376
	const WIN_OPENGL : uint32 = 2

	extern const mkwin : (title : byte#, x : int, y : int, w : int, h : int, flags : uint32 -> win)
	extern const freewin : (win : win -> void)

	type renderer = void#

	const RENDERER_ACCEL : uint32 = 2

	extern const mkrenderer : (win : win, index : int, flags: uint32 -> renderer)
	extern const copy : (r : renderer, tex : texture -> int)
	extern const present : (r : renderer -> void)
	extern const freerenderer : (r : renderer -> void)

	type texture = void#

	const PIXFMT_RGB332 : uint32 = 336660481
	const TEXACCESS_STREAM : int = 1

	extern const mktexture : (r : renderer, fmt : uint32, access : int, w : int, h : int -> texture)
	extern const update : (tex : texture, pixels : void#, pitch : int -> int)
	extern const freetexture : (tex : texture -> void)

	extern const delay : (ms : uint32 -> void)

	const SCANCODE_1 : uint8 = 30
	const SCANCODE_2 : uint8 = 31
	const SCANCODE_3 : uint8 = 32
	const SCANCODE_4 : uint8 = 33
	const SCANCODE_Q : uint8 = 20
	const SCANCODE_W : uint8 = 26
	const SCANCODE_E : uint8 = 8
	const SCANCODE_R : uint8 = 21
	const SCANCODE_A : uint8 = 4
	const SCANCODE_S : uint8 = 22
	const SCANCODE_D : uint8 = 7
	const SCANCODE_F : uint8 = 9
	const SCANCODE_Z : uint8 = 29
	const SCANCODE_X : uint8 = 27
	const SCANCODE_C : uint8 = 6
	const SCANCODE_V : uint8 = 25
	const SCANCODE_ESC : uint8 = 41

	extern const getkbd : ( -> uint8[256]#)
;;
#+END_SRC

Packages are imported with a =use= clause, and relative imports are supported if
the package name is wrapped in double quotes.

* Standard Library

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:

#+BEGIN_SRC myrddin
std.put("{} + {} = {}\n", 2, 2, 5)
#+END_SRC

There's a [[https://myrlang.org/doc/libtestr/][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.

* Conclusion

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 [[https://c9x.me/compile/][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!

[fn:1] At the moment, a Raspberry Pi B+. It does the job, but I'm afraid of blowing the 512MB RAM trying to run a full MediaGoblin instance on it.
[fn:2] Hell, the tutorial recommends limiting lines to 60 characters in length.
[fn:3] It's worth mentioning that irc.myr is /really/ impressive for what it is. It uses native [[https://git.eigenstate.org/npnth/libtermdraw.git/tree][terminal drawing library]] instead of ncurses, and the interface is probably the best out of any of these irssi-like clients. If I weren't so enamored with [[https://en.wikipedia.org/wiki/ERC_(software)][ERC]], I'd probably be using it as my daily driver. Also, I wrote this sentence prior to discovering that [[https://github.com/andrewchambers/qc][qc]] was written in Myrddin -- that's another example of a program written in Myrddin worth looking at.
[fn:4] I still maintain this complaint because it's true of the official documentation, but I need to give Ori a break here: in editing this article, I came across the page on his personal website describing it. See "[[https://eigenstate.org/notes/mcbind.html][Automatic C Binding Generation for Myrddin]]". I didn't use mcbind for the SDL binding library I put together because I thought function names like =sdl.SDL_UpdateTexture= would stick out like a sore thumb among the surrounding Myrddin code.
[fn:5] After posting this, [[https://mastodon.sdf.org/web/accounts/225228][wasamasa]] reached out to me with his attempt at a [[https://github.com/wasamasa/mal-candidates/tree/master/myrddin][Lisp interpreter]] in Myrddin. I had a fun time reading through what's there, so I figured I'd drop a link to it. Be sure to look at =notes.md=.