alloyc

Why write it again, in Alloy

This is what I am working on now, and it is deliberately on the site while it is still early. There have been three compilers for this language before it: two in C++, and a reference implementation in Zig written by an AI to my specification. This is the fourth, and the first written in Alloy itself, which is the point at which a language stops being a design and starts being something you have to live in.

How the pieces fit

Three repositories, one language. The specification, the packaged compiler binary and the standard library live together, and both compilers consume them as a submodule. That means the language this compiler implements and the language it is checked against are the same file, and neither implementation can drift from the spec without the drift being visible.

The reference implementation compiles this one. When the two disagree, one of them is wrong and I have to decide which, which is a better position to be in than having only one implementation and no way to tell whether the spec or the code is at fault. It is also the arrangement that makes writing the compiler in its own language possible at all, since something has to compile the first version.

What exists so far

An entry point that reads a source file and hands it to the tokenizer, and the beginning of the tokenizer itself. About 180 lines across three commits. It is written in real Alloy using the features I designed: module imports from the standard library, optional returns with payload capture, and error reporting.

The token kinds are synthesized at compile time from arrays of keywords and operators, so adding a new token means editing exactly one place rather than a declaration, a switch and a name table. That is the first thing built using Alloy's own compile-time machinery rather than merely specified, and compile-time power was the reason for the whole project back in 2022.

What I already suspect is wrong

Alloy has one rule underneath everything else, which is that things should be explicit. The place I am least sure I held to it is capture semantics. Pointers and references are pierced by default, so there is no * or -> anywhere, and that is a feature I still want. It is also the feature people find hardest to get used to, and I do not yet know whether that is a learning cost or a design mistake.

The sharper version of the same problem is const-ness. Alloy distinguishes a constant variable from a variable holding a constant pointer or reference, which is the right distinction to make. What it does not answer cleanly is what happens when one of those is captured. If a closure captures a mutable reference to a constant, or a constant reference to something mutable, what is the const-ness of the captured thing inside the closure? I can give an answer for each individual case. I cannot yet give one rule that produces all of them, and a rule I have to enumerate exceptions to is not explicit, it is just written down.

Writing the compiler in the language is how I expect to find out which of these actually hurts. A design flaw you can reason about in the abstract is a different thing from one you hit forty times in an afternoon.

Where it is

Three commits old, with the tokenizer unfinished. There is no architecture here yet to describe and no result to claim. It is on the site because it is the active work.