Blueberry Wren Thoughts

Flat/Non-higher-order construction of ANF via mutable holes

2026-05-14T00:00:00+00:00

Flat/Non-higher-order construction of ANF via mutable holes</h1>
This post will describe an algorithm for constructing an ANF/similar IR from a functional-like base language with no closure usage, and with no related excess space requirements. This algorithm is as far as I know not new, and has apparently been known in imperative compilation for a while. However, I admittedly have no source for this, nor have I seen it described for functional-like languages.</p>
Thanks to Ryan Brewer and rpjohnst for their inspiration on this.</p>
If you are only interested in code, please skip to Implementation.</p>

Prerequisites</h2>

First, let us describe our input and output languages. Our input language will look like this:</p>

type </span>ml </span>=
</span>  | Let </span>of </span>string </span>* </span>ml </span>* </span>ml
</span>  | Name </span>of </span>string
</span>  | Int </span>of </span>int
</span>  | Add </span>of </span>ml </span>* </span>ml
</span>  | Print </span>of </span>ml
</span></code></pre>
This is meant to echo some simple functional programming language, and contains all the elements needed to demonstrate the algorithm.</p>
Our output language will look like a lexically-scoped flat ANF-style construction, with all lets at the toplevel.
The goal is to convert from our input ml</code> to this language.</p>
type </span>base </span>=
</span>  | Name </span>of </span>string
</span>  | Add </span>of </span>string </span>* </span>string
</span>  | Int </span>of </span>int
</span>  | Print </span>of </span>string
</span>
</span>type </span>anf </span>=
</span>  | Let </span>of </span>string </span>* </span>base </span>* </span>anf
</span>  | Done </span>of </span>string
</span>  | Hole </span>of </span>anf option ref
</span></code></pre>
The notable addition is the Hole</code> constructor in anf</code>, the purpose of which will be described now.</p>
The premise</h2>
Imagine we are trying to convert the term</p>
let </span>x </span>=
</span>  </span>let </span>y </span>= </span>2 </span>in
</span>  y </span>+ </span>1
</span>in
</span>x </span>+ </span>2
</span></code></pre>
When we arrive at the body of x</code>, we have a conundrum. We need to put the conversion of y</code> before x</code>,
so that using y</code> is well-scoped. Hence, we must convert y</code> before we can continue. How do we use this conversion, though?
x</code>'s content needs to be put in the anf</code> field of y</code>'s Let</code>, so it's not clear how to both convert y</code> before x</code> and
to use x</code>'s finished conversion in y</code>.</p>
One "traditional" method of solving this is via continuations, where y</code> is passed a closure representing "what to do next", after it
converts its body. We can then put x</code>'s content in that closure, which will be invoked later. This has two main flaws:</p>

It uses excess space. A conversion of a term will allocate ~2x the memory "needed"; it must allocate for the ANF construction itself, and for the closures needed during the construction.</li>
It is slower, due to the aforementioned closure allocation and application.</li>
</ul>
This method resolves these.</p>
The algorithm</h2>
Recall that we left a Hole of anf option ref</code> field in our anf</code> type. I will denote a hole like this: [·]</code>.
The central idea is that our conversion of any given ml</code> fragment will return:</p>

The fragment itself.</li>
A name we can use to refer to what was bound in the fragment (In the conversion of addition/similar with nested content, names must be conjured.)</li>
The reference created by the hole, so that it may be filled.</li>
</ol>
val </span>convert : </span>ml </span>-> (</span>anf </span>* </span>string </span>* </span>anf option ref</span>)
</span></code></pre>
Consider this simplified example:</p>
let </span>x </span>=
</span>  </span>let </span>y </span>= </span>2 </span>in</span> y </span>+ </span>2
</span>in</span> x
</span></code></pre>
When we convert x</code>, this signals for the conversion of y</code>. There are two steps to converting a let</code> - we
must first convert the "head" (2</code>), and then the "body" (y</code>).</p>
Converting the head</code> will result in something of form</p>
let </span>y </span>= </span>2 </span>in 
</span>[·]
</span></code></pre>
Note that the hole is left to be filled later. This way, the conversion of y</code>'s head need know nothing about its environment.
We represent this in code via the Hole</code> constructor, which contains a reference to a fragment that either may be empty (None</code>)
or filled (Some ...</code>).
The conversion of the body can then proceed by first generating the expected addition, binding it to nm</code> so it may be referenced later:</p>
let </span>nm </span>=</span> y </span>+ </span>2 </span>in
</span>[·]
</span></code></pre>
We now need to get this fragment into the proper lexical scope. We can do this by plugging it into the hole left by the conversion of the head:</p>
let </span>y </span>= </span>2 </span>in
</span>[
</span>  </span>let </span>nm </span>=</span> y </span>+ </span>2 </span>in
</span>  [·]
</span>]
</span></code></pre>
Then, returning this fragment, the name bound (y</code>), and the reference to the inner hole, we can continue converting x</code>;
First, convert the head, using the name returned by the conversion of y</code>:</p>
let </span>x </span>=</span> nm </span>in
</span>[·]
</span></code></pre>
Then, the body:</p>
let </span>nm2 </span>=</span> x </span>in
</span>[·]
</span></code></pre>
Plug:</p>
let </span>x </span>=</span> nm </span>in
</span>[
</span>  </span>let </span>nm2 </span>=</span> x </span>in
</span>  [·]
</span>]
</span></code></pre>
And finally plug it into the hole returned by y</code>.</p>
let </span>y </span>= </span>2 </span>in
</span>[
</span>  </span>let </span>nm </span>=</span> y </span>+ </span>2 </span>in
</span>  [
</span>    </span>let </span>x </span>=</span> nm </span>in
</span>    [
</span>      </span>let </span>nm2 </span>=</span> x </span>in
</span>      [·]
</span>    ]
</span>  ]
</span>]
</span></code></pre>
We are left with a final hole we can plug with Done</code> to be explicit about the end of a control flow path.
One disadvantage of this strategy is that it does generate many unneeded names. Most of these can be avoided by carefully special
casing certain lets</code>, and the rest can be eliminated via a simple folding pass.</p>
Implementation</h2>
Below is a sample implementation of this algorithm, in OCaml.</p>


  The implementation can be unfolded here.
</summary>
type </span>ml </span>=
</span>  | Let </span>of </span>string </span>* </span>ml </span>* </span>ml
</span>  | Name </span>of </span>string
</span>  | Int </span>of </span>int
</span>  | Add </span>of </span>ml </span>* </span>ml
</span>  | Print </span>of </span>ml
</span>
</span>(* Suffix with ' to dodge OCaml annoyances. *)
</span>type </span>base </span>=
</span>  | Name' </span>of </span>string
</span>  | Add' </span>of </span>string </span>* </span>string
</span>  | Int' </span>of </span>int
</span>  | Print' </span>of </span>string
</span>
</span>type </span>anf </span>=
</span>  | Let' </span>of </span>string </span>* </span>base </span>* </span>anf
</span>  | Done' </span>of </span>string
</span>  | Hole' </span>of </span>anf option ref
</span>
</span>let </span>fresh_name </span>=
</span>  </span>let </span>counter </span>= ref </span>0 </span>in
</span>  </span>fun </span>() </span>->
</span>    incr counter;
</span>    </span>"nm" </span>^</span> string_of_int </span>!</span>counter
</span>
</span>(* A helper to make an anf fragment of form
</span>
</span>   let new_name = base in
</span>   [·]
</span> *)
</span>let </span>make_let_hole </span>(</span>base </span>: base</span>) : </span>(anf * string * anf option ref) </span>=
</span>  </span>let </span>name </span>=</span> fresh_name </span>() </span>in
</span>  </span>let </span>r </span>= ref </span>None </span>in
</span>  (Let' (name, base, Hole' r), name, r)
</span>
</span>let rec </span>convert </span>(</span>ml </span>: ml</span>) : </span>(anf * string * anf option ref) </span>=
</span>  </span>match</span> ml </span>with
</span>  </span>| </span>Name </span>nm </span>->
</span>                </span>(* Bind to a new name, and return.
</span>                   A case that can be eliminated in most cases.
</span>                   *)
</span>    make_let_hole (Name' nm)
</span>  </span>| </span>Int </span>i </span>->
</span>    make_let_hole (Int' i)
</span>  </span>| </span>Add (</span>a</span>, </span>b</span>) ->
</span>    </span>(* First, we convert `a` and `b` *)
</span>    </span>let </span>(a_anf, a_name, a_hole) </span>=</span> convert a </span>in
</span>    </span>let </span>(b_anf, b_name, b_hole) </span>=</span> convert b </span>in
</span>    </span>(* We chose a left-to-right evaluation order, so we
</span>       want to put `a` before `b`. Hence, plug `b`'s fragment
</span>       into the hole provided by `a`.
</span>       *)
</span>    a_hole </span>:= </span>Some b_anf;
</span>    </span>(* Then, we need a fragment for the addition itself. *)
</span>    </span>let </span>(add_anf, add_name, add_hole) </span>=
</span>      make_let_hole (Add' (a_name, b_name))
</span>    </span>in
</span>    </span>(* We put this in `b`'s hole. *)
</span>    b_hole </span>:= </span>Some add_anf;
</span>    </span>(* Finally, we return the whole expression.
</span>       Everything is contained within `a_anf`.
</span>       If the user wishes to refer to the result of this conversion,
</span>       they should use add_name.
</span>       If they wish to plug something into it,
</span>       they should use add_hole.
</span>       *)
</span>    (a_anf, add_name, add_hole)
</span>  </span>| </span>Print </span>body </span>->
</span>    </span>(* Print is similar. *)
</span>    </span>let </span>(body_anf, body_name, body_hole) </span>=</span> convert body </span>in
</span>    </span>let </span>(print_anf, print_name, print_hole) </span>=
</span>      make_let_hole (Print' body_name)
</span>    </span>in
</span>    body_hole </span>:= </span>Some print_anf;
</span>    (body_anf, print_name, print_hole)
</span>  </span>| </span>Let (</span>name</span>, </span>head</span>, </span>body</span>) ->
</span>    </span>let </span>(head_anf, head_name, head_hole) </span>=</span> convert head </span>in
</span>    </span>let </span>(body_anf, body_name, body_hole) </span>=</span> convert body </span>in
</span>    </span>(* We need to bind this let before body to ensure it is
</span>       properly lexically scoped.
</span>       *)
</span>    </span>let </span>let_anf </span>= </span>Let' (name, Name' head_name, body_anf) </span>in
</span>    </span>(* Then fill it as expected. *)
</span>    head_hole </span>:= </span>Some let_anf;
</span>    (head_anf, body_name, body_hole)
</span></code></pre>
</details>
I recommend toying with the conversion yourself, using utop</code> or similar.
In the following, I will "clean up" the output slightly, as to not make it unreadable.</p>
If we use our first example term:</p>
utop # </span>let </span>term </span>= </span>Let(</span>"x"</span>, Let(</span>"y"</span>, Int </span>2</span>, Add (Name </span>"y"</span>, Int </span>1</span>)), Add (Name </span>"x"</span>, Int </span>3</span>));;
</span>val </span>term : </span>ml </span>=
</span>  Let (</span>"x"</span>, Let (</span>"y"</span>, Int </span>2</span>, Add (Name </span>"y"</span>, Int </span>1</span>)), Add (Name </span>"x"</span>, Int </span>3</span>))
</span>
</span>utop # convert term;;
</span>(* Cleaned up: *)
</span>(</span>let </span>nm1 </span>= </span>2 </span>in
</span>let </span>y </span>=</span> nm1 </span>in
</span>let </span>nm2 </span>=</span> y </span>in
</span>let </span>nm3 </span>= </span>1 </span>in
</span>let </span>nm4 </span>=</span> nm2 </span>+</span> nm3 </span>in
</span>let </span>x </span>=</span> nm4 </span>in
</span>let </span>nm5 </span>=</span> x </span>in
</span>let </span>nm6 </span>= </span>3 </span>in
</span>let </span>nm7 </span>=</span> nm5 </span>+</span> nm6 </span>in
</span>Hole [·]
</span>, </span>"nm7"
</span>, </span><</span>empty reference</span>>
</span>)
</span></code></pre>
We can then plug the returned hole, as described.
Via some inspection, we can verify this is indeed correct, and conforms to our ANF-like form, as expected.</p>
As mentioned earlier, the large amount of duplicate names can be mitigated through strategies such as
special casing let _ = <direct base></code> and folding passes.</p>
Properties</h2>
Clearly, the algorithm does not use closures, or any indirect jumps. It does not allocate any more than needed for the representation of
the output program; there is no excessive closure allocation. I do not currently have a good way to test performance on real-world large inputs,
but I have no reason to believe it would not perform better than an equivalent higher-order version.</p>
Future work</h2>
I believe this method should be extendable to CPS as well, although I have not tried as of the moment. The "usual" higher-order CPS
conversion described in e.g. "Compiling with continuations, continued" looks quite similar to the higher-order presentation
of ANF conversion, so I would be interested in whether it can be similarly massaged into a mutable form.</p>



Type safe interpreters
2026-01-17T00:00:00+00:00
It is well known that most software has bugs^{[Citation needed]</i></sup>.
It is also well known that interpreters are mostly software^{1</a></sup>. One issue that one might
run into in an interpreter is type safety</em>: It may very well be possible for your
typed language's interpreter to nevertheless end up in a state where it is asked
to evaluate 1 + "hi!"</code>. What can we do about that?</p>}}
GADTs: Generalized ADTs2</a></sup></h2>
GADTs are a technique for increasing type safety in a program, by "indexing" a constructor by a type.
One of the canonical examples for this is an Option</code>-like. Imagine we wanted a type-safe way to ensure
that in some cases, we could always extract the value inside. One way of doing this is to add an extra
type parameter, and use that to mark whether something is inside. We will use OCaml for this demonstration.</p>
(* Dummy constructors; we are only using these for their types *)
</span>type </span>yes </span>= Yes
</span>type </span>no </span>= No
</span>
</span>type </span>(_, _) maybe </span>=
</span>      |  </span>^ </span>regular </span>"information inside" </span>type
</span>      </span>^ </span>marker </span>of </span>whether the information exists 
</span>  | Nothing : (</span>no</span>, </span>'a</span>) </span>maybe
</span>  | Just : </span>'a </span>-> (</span>yes</span>, </span>'a</span>) </span>maybe
</span></code></pre>
Note that we have used a different syntax than usual. Normally, we put a type parameter in the constructor,
like type 'a list</code>, and then use that throughout ('a * 'a list</code>). However, as we are changing that type
in the "return" of the constructor, we need a syntax that allows us to change that. _</code> marks a type parameter
we "don't need to name" (as we always specify it), and in this case, we always specify both. Then, we
add our elements before a -></code>, mimicking a function. The general form of this in OCaml is t1 * t2 * ... * tn -> t</code>.</p>
Now, if we have something of type (yes, 'a) maybe</code>, we know it contains a value! The only other way a maybe</code> can be
formed is via Nothing</code>, but that gives it type (no, 'a) maybe</code>, so it'd be type-incorrect. This means we
can write a function like</p>
let </span>get </span>(</span>x </span>: (yes, 'a) maybe</span>) -> '</span>a </span>= 
</span>  </span>match</span> x </span>with
</span>  </span>| </span>Just </span>a </span>-> a
</span></code></pre>
and have it be total; there is no missing case, because the missing case is a type error. Note that when writing a
function like or_else : (_, 'a) maybe -> 'a -> 'a</code>, we need to use this interesting piece of syntax:</p>
let </span>or_else </span>: </span>type m. (m, 'a) maybe -> 'a -> 'a </span>= fun </span>x def </span>-> 
</span>  </span>match</span> x </span>with
</span>  </span>| </span>Just </span>a </span>-> a
</span>  </span>| </span>Nothing -> def
</span></code></pre>
This is as otherwise OCaml's normal type inference can get in our way and infer the wrong type, leading to a type error.3</a></sup></p>
Type safe interpreters</h2>
How does this allow us to get a more type-safe interpreter, though? Well, let's start by introducing our expression
type:</p>
type </span>_ expr </span>=
</span></code></pre>
We've added space for a type parameter. What should integers and booleans look like? Maybe we should paramaterize our expressions
by the type they "evaluate to" - that way, when we have a 'a expr</code>, we know that it'll evaluate to something
of type 'a</code>. Hence:</p>
  </span>| </span>Lit : </span>int </span>-> </span>int</span> expr
</span>  </span>| </span>Bool : </span>bool </span>-> </span>bool</span> expr
</span></code></pre>
Now, we want to add a case for Add</code> and Negate</code>. Naturally, we shouldn't be able to add two booleans, so let's restrict it
to only taking in int expr</code>s, and similar for negate. We also know that these should return integers, too.</p>
  </span>| </span>Add : </span>int </span>expr </span>* </span>int </span>expr </span>-> </span>int</span> expr
</span>  </span>| </span>Negate : </span>int </span>expr </span>-> </span>int</span> expr
</span></code></pre>
We've already added type safety! It's impossible to write Add (Bool true, Lit 5)</code>, because Add</code> expects a int expr</code>,
but Bool true</code> is a bool expr</code>. Let's keep going: <=</code> (or Leq</code>) should take two integers and return a boolean,
and If</code> should take a boolean as its first argument, but anything for its second and third.</p>
  </span>| </span>Leq : </span>int </span>expr </span>* </span>int </span>expr </span>-> </span>bool</span> expr
</span>  </span>| </span>If : </span>bool </span>expr </span>*</span> '</span>a expr </span>*</span> '</span>a expr </span>-> 'a expr
</span></code></pre>
Note that we can still use generic parameters, like 'a</code> here - we just need to think about when it makes sense to do so,
to get the type safety we want.</p>
Now for functions. What should a function look like here? One way of implementing them is with a "Higher-order abstract syntax"(HOAS)4</a></sup> approach,
where we use the functions of the host language to make functions in the interpreted language. In that case, we should
take a function as the argument to our constructor, but when what is our result type? That function type! We'll
need to know it later to safely write Apply</code>, so we "store" it in the type now. We also want the function
to take and return an _ expr</code>, so we can do constructions like Lam (fun x -> Add(x,x))</code>.</p>
  </span>| </span>Lam : ('</span>a expr</span> -> '</span>b expr</span>) -> ('a expr -> 'b expr) expr
</span></code></pre>
Note that the function is not an expr</code> at first, as otherwise we would have no way to construct it in the first
place. (Remember, this is how we make functions.)</p>
Then Apply</code>. It should take in a function, and a value, and then return the function applied to the value.
This hence translates as:</p>
  </span>| </span>Apply : ('</span>a expr</span> -> '</span>b expr</span>) </span>expr </span>*</span> '</span>a expr</span>-> 'b expr
</span></code></pre>
As a finale, we'll add pairs and projections. I won't elaborate on these, hoping that it's becoming obvious how
they work.</p>
  </span>| </span>Pair : '</span>a expr </span>*</span> '</span>b expr </span>-> ('a </span>*</span> 'b) expr
</span>  </span>| </span>Fst : ('</span>a</span> * '</span>b</span>) </span>expr </span>-> 'a expr
</span>  </span>| </span>Snd : ('</span>a</span> * '</span>b</span>) </span>expr </span>-> 'b expr
</span></code></pre>
All of the above in one code block</summary>
type </span>_ expr </span>=
</span>  | Lit : </span>int </span>-> </span>int expr
</span>  | Bool : </span>bool </span>-> </span>bool expr
</span>  | Add : </span>int expr </span>* </span>int expr </span>-> </span>int expr
</span>  | Negate : </span>int expr </span>-> </span>int expr
</span>  | Leq : </span>int expr </span>* </span>int expr </span>-> </span>bool expr
</span>  | If : </span>bool expr </span>* </span>'a expr </span>* </span>'a expr </span>-> </span>'a expr
</span>  | Lam : (</span>'a expr </span>-> </span>'b expr</span>) -> (</span>'a expr </span>-> </span>'b expr</span>) </span>expr
</span>  | Apply : (</span>'a expr </span>-> </span>'b expr</span>) </span>expr </span>* </span>'a expr </span>-> </span>'b expr
</span>  | Pair : </span>'a expr </span>* </span>'b expr </span>-> (</span>'a </span>* </span>'b</span>) </span>expr
</span>  | Fst : (</span>'a </span>* </span>'b</span>) </span>expr </span>-> </span>'a expr
</span>  | Snd : (</span>'a </span>* </span>'b</span>) </span>expr </span>-> </span>'b expr
</span></code></pre>
</details>
Examples</h2>
Now let's look at some examples and their types.</p>
utop # Lit </span>5</span>;;
</span>-</span> : </span>int</span> expr </span>= </span>Lit </span>5
</span>
</span>utop # Bool </span>true</span>;;
</span>-</span> : </span>bool</span> expr </span>= </span>Bool </span>true
</span>
</span>utop # Add (Lit </span>4</span>, Lit </span>5</span>);;
</span>-</span> : </span>int</span> expr </span>= </span>Add (Lit </span>4</span>, Lit </span>5</span>)
</span>
</span>utop # Lam (</span>fun </span>f </span>-> f);;
</span>-</span> : ('a expr -> 'a expr) expr </span>= </span>Lam </span><</span>fun</span>>
</span>
</span>utop # Apply (Lam (</span>fun </span>x </span>-> Add(x,x)), Lit </span>5</span>);;
</span>-</span> : </span>int</span> expr </span>= </span>Apply (Lam </span><</span>fun</span>></span>, Lit </span>5</span>)
</span>
</span>utop # Lam (</span>fun </span>b </span>-> If (b, Lit </span>5</span>, Lit </span>6</span>));;
</span>-</span> : (</span>bool</span> expr -> </span>int</span> expr) expr </span>= </span>Lam </span><</span>fun</span>>
</span></code></pre>
We have that a construction like Lam (fun b -> If (b, b, Lit 6))</code> is not just an error, but a type error</em>!
This means it's caught at compile time!</p>
utop # Lam (</span>fun </span>b </span>-> If (b, b, Lit </span>6</span>));;
</span>                               </span>^^^^^
</span>Error: This constructor has </span>type </span>int</span> expr
</span>       but an expression was expected of </span>type </span>bool</span> expr
</span>       Type </span>int</span> is </span>not</span> compatible </span>with type </span>bool
</span></code></pre>
The actual evaluator</h2>
From here, the evaluator itself is very simple. We just write the interpretation of our language, as usual:</p>
let rec </span>eval </span>: </span>type t. t expr -> t </span>= fun </span>x </span>->
</span>  </span>match</span> x </span>with
</span>  </span>| </span>Lit </span>a </span>-> a
</span>  </span>| </span>Bool </span>b </span>-> b
</span>  </span>| </span>Add (</span>a</span>,</span>b</span>) -> eval a </span>+</span> eval b
</span>  </span>| </span>Negate </span>a </span>-> </span>- </span>(eval a)
</span>  </span>| </span>Leq (</span>a</span>,</span>b</span>) -> (eval a) </span><= </span>(eval b)
</span>  </span>| </span>If (</span>cond</span>,</span>l</span>,</span>r</span>) -> (</span>if </span>(eval cond) </span>then </span>(eval l) </span>else </span>(eval r))
</span>  </span>| </span>Lam </span>f </span>-> (</span>fun </span>x </span>-> f x)
</span>  </span>| </span>Apply (</span>f</span>,</span>x</span>) -> eval ((eval f) x)
</span>  </span>| </span>Pair (</span>a</span>,</span>b</span>) -> (eval a, eval b)
</span>  </span>| </span>Fst </span>a </span>-> fst (eval a)
</span>  </span>| </span>Snd </span>a </span>-> snd (eval a);;
</span></code></pre>
The Lam</code> and Apply</code> cases are interesting. In the former, we need to return a function</em> of type 'a expr -> 'b expr</code>.
We can start by introducing a function fun x -></code>, but we have f : 'a expr -> 'b expr</code>, so we just apply it.
In the latter, we need to eval f</code> to get a function 'a expr -> 'b expr</code> from f</code>, which is of type
('a expr -> 'b expr) expr</code>. We can then pass it x</code>, which is of type 'a expr</code> to get a 'b expr</code>, which
we must then evaluate again to get a 'b</code>.</p>
Now we can run the above examples.</p>
utop # eval (Lit </span>5</span>);;
</span>-</span> : </span>int </span>= </span>5
</span>
</span>utop # eval (Bool </span>true</span>);;
</span>-</span> : </span>bool </span>= </span>true
</span>
</span>utop # eval (Add (Lit </span>4</span>, Lit </span>5</span>));;
</span>-</span> : </span>int </span>= </span>9
</span>
</span>utop # eval (Lam (</span>fun </span>f </span>-> f));;
</span>-</span> : '_weak1 expr -> '_weak1 expr </span>= <</span>fun</span>>
</span>(* The `_weak1` is due to an internal OCaml limitation, called the "value restriction". *)
</span>
</span>utop # eval (Apply (Lam (</span>fun </span>x </span>-> Add(x,x)), Lit </span>5</span>));;
</span>-</span> : </span>int </span>= </span>10
</span>
</span>utop # eval (Lam (</span>fun </span>b </span>-> If (b, Lit </span>5</span>, Lit </span>6</span>)), Bool </span>true</span>);;
</span>-</span> : </span>bool</span> expr -> </span>int</span> expr </span>= <</span>fun</span>>
</span>(* Note that this gives us a function returning `int expr`. We'd need to either use `Apply`, like below,
</span>   or `eval` to get an `int` out of it.
</span>*)
</span>
</span>utop # eval (Apply (Lam (</span>fun </span>b </span>-> If (b, Lit </span>5</span>, Lit </span>6</span>)), Bool </span>true</span>));;
</span>-</span> : </span>int </span>= </span>5
</span></code></pre>
Remember, all of the above is completely type safe! We have succesfully constructed an interpreter that can never
type error.</p>
How do you apply this?</h2>
In short, it can be hard. One way is to have a "base" language that's parsed, and then have your typechecker produce
a representation like the above that you then know is type correct. However, this does prevent typechecker bugs
from sneaking through, which was our entire goal!</p>
To some extent, this is kicking the bucket down the road - you are now relying that your "host language"'s typechecker
is correct. However, this is a numbers game; if you're writing in OCaml or Haskell or similar, the chances of that
are very very high unless you're using extremely weird features.</p>
Aside: Denotional semantics</h2>
The astute may have noted that this is essentially a version of denotional semantics. We're interpreting into the
type-safe domain of the host language to ensure that the types always line up (as they must, for the interpretation
to succeed, and the typechecker of the host language ensures that).</p>
All code</h2>
All the code in one block, for pasting.</summary>
type </span>_ expr </span>=
</span>  | Lit : </span>int </span>-> </span>int expr
</span>  | Bool : </span>bool </span>-> </span>bool expr
</span>  | Add : </span>int expr </span>* </span>int expr </span>-> </span>int expr
</span>  | Negate : </span>int expr </span>-> </span>int expr
</span>  | Leq : </span>int expr </span>* </span>int expr </span>-> </span>bool expr
</span>  | If : </span>bool expr </span>* </span>'a expr </span>* </span>'a expr </span>-> </span>'a expr
</span>  | Lam : (</span>'a expr </span>-> </span>'b expr</span>) -> (</span>'a expr </span>-> </span>'b expr</span>) </span>expr
</span>  | Apply : (</span>'a expr </span>-> </span>'b expr</span>) </span>expr </span>* </span>'a expr </span>-> </span>'b expr
</span>  | Pair : </span>'a expr </span>* </span>'b expr </span>-> (</span>'a </span>* </span>'b</span>) </span>expr
</span>  | Fst : (</span>'a </span>* </span>'b</span>) </span>expr </span>-> </span>'a expr
</span>  | Snd : (</span>'a </span>* </span>'b</span>) </span>expr </span>-> </span>'b expr</span>;;
</span>
</span>let rec </span>eval </span>: </span>type t. t expr -> t </span>= fun </span>x </span>->
</span>  </span>match</span> x </span>with
</span>  </span>| </span>Lit </span>a </span>-> a
</span>  </span>| </span>Bool </span>b </span>-> b
</span>  </span>| </span>Add (</span>a</span>,</span>b</span>) -> eval a </span>+</span> eval b
</span>  </span>| </span>Negate </span>a </span>-> </span>- </span>(eval a)
</span>  </span>| </span>Leq (</span>a</span>,</span>b</span>) -> (eval a) </span><= </span>(eval b)
</span>  </span>| </span>If (</span>cond</span>,</span>l</span>,</span>r</span>) -> (</span>if </span>(eval cond) </span>then </span>(eval l) </span>else </span>(eval r))
</span>  </span>| </span>Lam </span>f </span>-> (</span>fun </span>x </span>-> f x)
</span>  </span>| </span>Apply (</span>f</span>,</span>x</span>) -> eval ((eval f) x)
</span>  </span>| </span>Pair (</span>a</span>,</span>b</span>) -> (eval a, eval b)
</span>  </span>| </span>Fst </span>a </span>-> fst (eval a)
</span>  </span>| </span>Snd </span>a </span>-> snd (eval a);;
</span></code></pre>
</details>



No, I won't do the same joke twice. Most of the time. ↩</a></p>
</li>

I am not going into what "ADT" stands for, as it's a whole nother debate. ↩</a></p>
</li>

It may for example eagerly infer (yes, 'a) maybe -> (yes, 'a) maybe</code>, which is a type error, as we also want to handle the (no, 'a) maybe</code> Nothing</code> case. ↩</a></p>
</li>

Higher-order abstract syntax. A bit too in-depth to explore in full right now, but worth exploring. ↩</a></p>
</li>
</ol>
</footer>


Axiom J in Homotopy Type Theory (HoTT)
2026-01-01T00:00:00+00:00
Preface</h2>
Happy new years!</p>
Notation</h3>
∀</code> may be used in place of a Pi-type in some cases. A nested Π (a b : A). ...</code> (or sim. for Σ</code>) represents Π (a : A). Π (b : A). ...</code>.</p>
J</h3>
Axiom J is the following:</p>
Given:
</span>A : Type
</span>x y : A
</span>P : Π (a b : A). a = b -> Type
</span>with
</span>P x x refl
</span>and
</span>eq : x = y
</span>
</span>we can conclude
</span>
</span>P x y eq
</span></code></pre>
where refl : ∀x. x = x</code>. In short, for any property P</code>, if P</code> is true for x x refl</code>,
and we know that eq : x = y</code>, then P</code> is true for x y eq</code>.</p>
In a non-cubical context, this is obvious - the only proof of x = y</code> for any x</code> and y</code> is refl</code>, so it's close to a no-op. However, in HoTT, where there may
be many proofs of x = y</code>, Axiom J is slightly less obvious. Why can we conclude that P</code> is true for any path if we are only given that
it is true at refl</code>?</p>
Why?</h2>
First, let's curry P</code>, turning the initial arguments from a Pi-type to a Sigma-type:</p>
P : Π (a b : A). a = b -> Type
</span>==>
</span>P : (Σ(a : A). Σ(b : A). a = b) -> Type
</span></code></pre>
And rewrite the above accordingly.</p>
Given:
</span>A : Type
</span>x y : A
</span>P : (Σ(a : A). Σ(b : A). a = b) -> Type
</span>with
</span>P (x, x, refl)
</span>and
</span>eq : x = y
</span>
</span>we can conclude
</span>
</span>P (x, y, eq)
</span></code></pre>
We will first apply the principle that if a = b</code>, then P a -> P b</code>, generally called something like subst</code>itution. We can use P (x, x, refl)</code> as our "P a</code>". We then aim to show that:</p>
Given:
</span>eq : x = y
</span>then
</span>(x, x, refl) = (x, y, eq)
</span></code></pre>
The first element is obvious - clearly x = x</code>. Now we have to show that (x, refl) = (y, eq)</code>.
This seems impossible! We do not</em> have that refl = eq</code>, due to the nature of HoTT.</p>
Let's approach this by analysing the type of (x, refl)</code> and (y, eq)</code> (it's the same for both; otherwise the equality above wouldn't make sense).</p>
Looking at the type of P</code> above, we can conclude that</p>
(x, refl) : Σ(b : A). x = b
</span>                      ^ note the `x` here we got from 
</span>                        the first element of the tuple
</span>and then necessarily
</span>(y, eq)   : Σ(b : A). x = b
</span></code></pre>
Now for the trick. While we do not</em> have that refl = eq</code>, we don't actually need it!
It turns out that we can prove that any element of Σ(b : A). x = b</code> is equal to any other element of Σ(b : A). x = b</code>, irregardless of
the proof of equality used - in other words, Σ(b : A). x = b</code> only has one inhabitant. This property (only having one inhabitant) is called "contractibility".</p>
A "proper" proof of this requires some careful thinking
(One can be found here as Singleton-contract</code>, in Cubical Agda, courtesy of the 1lab</a>,
and it's Lemma 3.11.8 in the HoTT book, at time of writing.), but I'll give an informal one here.</p>
Consider what Σ(b : A). x = b</code> means</em>. One way of interpreting it is like it's a subset - that
"Σ(b : A). x = b</code> is the type of things that are elements of A</code> equal to x</code>".
However, there's only one of those! Namely, x</code> itself. If we chose anything else, we wouldn't have x = b</code> in the first place.
This means that our choice of equality doesn't matter at all - when we consider the tuple as a whole, there can only be one inhabitant.
Hence, as we already have that x = y</code>, we have (x, refl) = (x, eq) = (y, eq)</code>, completing our proof.</p>
TLDR</h2>

</li>
</ol>
J : Π (A : Type) 
</span>      (x y : A)
</span>      (eq : x = y)
</span>      (P : Π(a b : A). x = y -> Type).
</span>         P x x refl 
</span>      -> P x y eq
</span>Goal : P x y eq
</span></code></pre>

Consider the equivalent "curried" version, so curry P</code>:</li>
</ol>
J : Π (A : Type) 
</span>      (x y : A)
</span>      (eq : x = y)
</span>      (P : (Σ(a : A). Σ(b : A). a = b) -> Type).
</span>         P (x, x, refl)
</span>      -> P (x, y, eq)
</span>Goal : P (x, y, eq)
</span></code></pre>

Use subst : a = b -> P a -> P b</code>:</li>
</ol>
Goal : (x, x, refl) = (x, y, eq)
</span></code></pre>

Use that Π x a b. a = b -> (x, a) = (x, b)</code> (with a = (x, refl)</code> and b = (y, eq)</code>:</li>
</ol>
Goal : (x, refl) = (y, eq)
</span></code></pre>

Use that Σ(b : A). x = b</code> is contractible (Π (one two : Σ(b : A). x = b)). one = two</code>):</li>
</ol>
Done!
</span></code></pre>
A handwavy "proof term" may look like (ommitting some "obvious" arguments, as one may do with implicit arguments in Agda):</p>
Given:
</span>subst : Π P a b. a = b -> P a -> P b
</span>subst-fst : Π x y p q. (x , p) = (x , q) -> x = y -> (x , p) = (y , q)
</span>pair-snd-eq : Π x a b. a = b -> (x , a) = (x , b)
</span>singleton-contractible : Π x (one two : Σ(b : A). x = b)). one = two
</span>
</span>We have:
</span>
</span>J : Π (A : Type) 
</span>      (x y : A)
</span>      (eq : x = y)
</span>      (P : (Σ(a : A). Σ(b : A). a = b) -> Type).
</span>         P x x refl 
</span>      -> P x y eq
</span>J A x y eq P Pxxrefl = 
</span>  subst  (pair-snd-eq singleton-contractible) Pxxrefl
</span></code></pre>


Written in Pure Sea
2025-12-19T00:00:00+00:00
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣴⣶⠾⠿⠿⠯⣷⣄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
</span>⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣼⣾⠛⠁⠀⠀⠀⠀⠀⠀⠈⢻⣦⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
</span>⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣾⠿⠁⠀⠀⠀⢀⣤⣾⣟⣛⣛⣶⣬⣿⣆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
</span>⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣾⠟⠃⠀⠀⠀⠀⠀⣾⣿⠟⠉⠉⠉⠉⠛⠿⠟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
</span>⠀⠀⠀⠀⠀⠀⠀⠀⢀⣴⡟⠋⠀⠀⠀⠀⠀⠀⠀⣿⡏⣤⠀⠀__/\웃_⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
</span>⠀⠀⠀⠀⠀⠀⠀⣠⡿⠛⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⣷⡍⠀⠀\____/⠀⠀⠀⢀⣀⣀⣤⣤⣤⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀ 
</span>⠀⠀⠀⠀⠀⣠⣼⡏⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠙⠷⣤⣤⣠⣤⣤⡤⡶⣶⢿⠟⠹⠿⠄⣿⣿⠏⠀⣀⣤⡦⠀⠀⠀⠀⣀⡄
</span>⢀⣄⣠⣶⣿⠏⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠉⠓⠚⠋⠉⠀⠀⠀⠀⠀⠀⠈⠛⡛⡻⠿⠿⠙⠓⢒⣺⡿⠋⠁
</span>⠉⠉⠉⠛⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠉⠁⠀
</span></code></pre>
I don't have great C legs.</p>


Horrible answers to "What is a type?"
2025-11-17T00:00:00+00:00

A set.</li>
Absolutely not a set.</li>
An element of a category.</li>
A proposition.</li>
A chosen fixed point of a generating function.</li>
The initial algebra/final coalgebra of a generating endofunctor over a reasonable base category (say, Set</code>).</li>
A metaphorical representation of bytes.</li>
A membership function UNIV → bool</code>.</li>
That thing you put after the :</code> to make the computer stop yelling at you :(</li>
as any</code></li>
Propaganda made up by Big Typechecker to make us complacent.</li>
Nerd shit.</li>
The archetype of person that you tend to feel attracted to romantically.</li>
A metal plate with a glyph, used for printing ink onto paper.</li>
</ul>


Opinion piece: On Zig (and the design choices within)
2025-10-14T00:00:00+00:00
(From someone who has spent far too much time thinking about the designs of programming languages)</p>
This post is split up into a few sections. I would also like to preface this post with:</p>

This is a little bit of a rant. I believe it presents some very reasonable points about Zig as a language, but it's not going to be
perfect or completely objective. It is an opinion piece, and you're free to ignore it if you want.</li>
Existing memory safe languages are not perfect. Rust will be used as an example quite a bit, as from what is currently available, it embodies closer to what I think is reasonable in a programming language. However, there is still much room for improvement in this space.</li>
All of the following is ultimately my opinion. If you disagree, you are welcome to find me somewhere on the internet and ask me more.</li>
I bear no grudge or ill will against anyone who contributes to, works on, or is otherwise involved in the Zig community. The following are things I have noted about the language, not the people behind it. If you enjoy Zig, go and write it, and make cool stuff - I am not the programming language police.</li>
Exception to the above: I have one gripe about the Zig community. This gripe "targets" no one person in particular; rather, larger trends.</li>
</ol>
Ideological differences</h2>
Memory</h3>
First, and very much foremost, Zig is not memory safe. This is, in my opinion, the most
egregious thing in this post, by a very large margin. Moreso, Zig does not make any attempt to
be memory safe -
it can catch some things at runtime, with specific allocators, but so can C these days. Indeed, there
are some cases, like use-after-realloc, that asan</code> can catch and Zig cannot.</p>
A language in the modern day that does not make an attempt at memory safety is, in my opinion, not reasonable. It has been shown that in some areas, up to 70% of security bugs are due to memory safety issues (Source</a>).</p>
I subscribe to the idea that the user must be constrained. It is perhaps harsh to say, but for large and complex programs, I believe that there are very few programmers who will write memory-correct code nine times out of ten. When writing code with others, that goes down. I personally do not believe I fit into that category.</p>
The fact that Zig allows the user to write faulty software is supported by various somewhat informal, but still useful, statistics. Notably, the following statistic disregard duplicates, and unreported errors. However, general trends are still of note.</p>
UPDATE: Someone has done a much more thorough analysis of crashes in JS runtimes! Thank you to the authors of the Javascript Runtime Segfault Tracker</a>, which demonstrates my point very effectively. To quote the person who sent me this: "it's a log scale. i'll let you guess which runtime is responsible for that."</p>
For posterity, I leave my own analysis below:</p>
Here are some:</summary>

The Rust compiler has had a lifetime 59,780 issues reported. Of these, 4,158 contain one of "crash", "segmentation fault", or "segfault".</li>
The Zig compiler has had a lifetime 13,269 issues reported. Of these, 2,260 contain one of "crash", "segmentation fault", or "segfault".</li>
</ol>
This means that, roughly:</p>

7% of lifetime issues reported in the Rust compiler are crashes.</li>
17% of lifetime issues reported in the Zig compiler are crashes.</li>
</ol>
Not ideal.</p>

The Node/v8 JS runtime, written partially itself in JS and partially in C++, has had a lifetime 19,631 issues reported, 1,710 of which contain one of the above keywords.</li>
The Deno JS runtime, written primarily in Rust, has had a lifetime 13,422 issues reported, 552 of which contain one of the above keywords.</li>
The Bun JS runtime, written in Zig, has had a lifetime 13,828 issues reported, 3676 of which contain one of the above keywords.</li>
</ol>
Again, this roughly means:</p>

8.7% of lifetime issues reported in Node are crashes.</li>
4.1% of lifetime issues reported in Deno are crashes.</li>
26.5% (!!!) of lifetime issues reported in Bun are crashes.</li>
</ol>
Also not great. Again, these statistics are slightly off at best simply due to the nature of their collection, but the trends do not lie.</p>
</details>
If you're not reading the above: It can be summarized as "Pretty bad."</p>
Philosophy</h3>
At one point, this part of the article contained a runthrough of the zig zen</code>, and my opinions on each bullet point. I have decided that that is not a constructive discussion of Zig. It suffices for me to say that I do not believe Zig particularly embodies its own zen.</p>
Practical</h2>
Comptime</h3>
Zig does generics in an odd way. I believe this is the best way of putting it.
This post is not meant to be, nor will it contain, a proper explanation of Zig's comptime</code>
capabilities, so I refer the reader to the wider internet there. However, doing generics
with "normal" code means that there are multiple ways to write the same generic function.
There is no standardization between different libraries, different styles of writing code, and
different users of Zig. Every person can do generics in their own special way.</p>
This obviously has slightly dire effects on readability. In practice, most Zig users are reasonable enough
to stick to some "common patterns" of doing generics and similar, but it is widely known that if the user is giving the ability to do something, it will be done. I believe that generics are important enough they should be first class.</p>
Arguments can be made that Zig's comptime is also useful for other things, not just generics. Some examples I have been given are conditional compilation, and variadic functions. Beyond these, I am yet to see a convincing motivating example that requires</em> the machinery that Zig provides. Every such example can, in my experience, be solved with less powerful (and hence, for the most part, less confusing) machinery.</p>
As a result, I am inclined to believe that Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot.</p>
I am personally a proponent of a good macro system, but I will readily admit people can also go overboard with one of those.</p>
Casting</h3>
Zig's casting is a bit cumbersome. To cast a float to a specific int width, for example, must be done with @as(i32, @intFromFloat(flt))</code>. Bit of a mouthful. Inference can help here (For example if a variable is already known to be a i32</code>, the outer cast is not needed), but I would think that with Zig's comptime abilities, this could be made a bit nicer. Luckily, it is common Zig practice to annotate everything if possible, so this does come up slightly less in practice. It is still a bit bulky however.</p>
Float to int casting additionally can invoke undefined behavior if the float is outside the integer's range. I personally prefer truncating semantics, with perhaps a specialized method (intFromFloatUnsafe</code>?) for UB semantics. That's more of a personal preference though.</p>
Semantics</h2>
Result location semantics (RLS)</h3>
See here</a>.</p>
Result location semantics are in theory a quite nice idea. Knowing predictably where things are going to be placed in memory is, of course, good for any systems-adjacent language! In practice, there are several choices within RLS that I find counterintuitive. Take the following example, where we attempt to swap two struct members in place:</p>

</span>const</span> std </span>= @</span>import</span>(</span>"std"</span>);
</span>const</span> What </span>= </span>struct </span>{
</span>    a: i32,
</span>    b: i32,
</span>};
</span>
</span>pub </span>fn </span>main</span>() void {
</span>    var x: What </span>= </span>.{ .a </span>= </span>1</span>, .b </span>= </span>2 </span>};
</span>    x </span>=</span> What { .a </span>=</span> x.b, .b </span>=</span> x.a };
</span>    std.log.</span>info</span>(</span>"x: {}"</span>, .{x});
</span>
</span>    var y: What </span>= </span>.{ .a </span>= </span>1</span>, .b </span>= </span>2 </span>};
</span>    y </span>= </span>.{ .a </span>=</span> y.b, .b </span>=</span> y.a };
</span>    std.log.</span>info</span>(</span>"y: {}"</span>, .{y});
</span>}
</span></code></pre>
This outputs the following:</p>
info: x: .{ .a </span>= </span>2</span>, .b </span>= </span>1 </span>}
</span>info: y: .{ .a </span>= </span>2</span>, .b </span>= </span>2 </span>}
</span></code></pre>
I will note that the equivalent C can only be written in the former style, and it prints the former.</p>
The only difference between the latter and the former is whether the type name is present. This is intended behavior! Indeed, this very example is given in the Zig reference, a fact that I find odd. Why give a warning against something when you could just fix it? Zig does not have move or copy constructors; I do not think there is very much reason for the latter to ever behave the way it does. One extra register is all you ever need, even for an arbitrary parallel move! (Source</a>.)</p>
Pointer reference optimization</h3>
In its previous form, PRO has been removed from Zig. There was a long period where this would print 5</code>:</p>
const</span> std </span>= @</span>import</span>(</span>"std"</span>);
</span>
</span>const </span>AAAA </span>= </span>struct </span>{
</span>    foo: [100]u32,
</span>};
</span>
</span>fn </span>kindabad</span>(</span>a</span>: AAAA, </span>b</span>: *AAAA) void {
</span>  b.</span>*</span>.foo[</span>0</span>] </span>= </span>5</span>;
</span>
</span>  std.debug.</span>print</span>(</span>"unideal: {}"</span>, .{ a.foo[</span>0</span>] });
</span>}
</span>
</span>pub </span>fn </span>main</span>() </span>!</span>void {
</span>    var f: </span>AAAA </span>=</span> undefined;
</span>
</span>    f.foo[</span>0</span>] </span>= </span>0</span>;
</span>
</span>    </span>kindabad</span>(f, </span>&</span>f);
</span>}
</span></code></pre>
As Zig would correctly, per PRO at the time, but incorrectly per common sense, pass a</code> as a reference.</p>
This is actually mildly unfortunate. It's a very interesting optimization, and being able to guarantee behavior around optimization of parameter passing would also be quite beneficial. Unfortunately, Zig simply does not have the level of control needed to do it. Aliasing is freely allowed, and in order to make PRO work, it cannot be. Rust can, and in many cases does, do this! It's a shame Zig has to miss out.</p>
There is current work to make PRO work in the case of pure functions (Source</a>), so I remain hopeful that it will return in some form eventually.</p>
Misc. Improvable things</h2>
Speed</h3>
The Zig compiler is not particularly fast. The LLVM backend even more so; compared to Clang, (which has the home field advantage, but can still be quite slow), and by my measurements, Clang is consistently between 3-10x faster. A new Zig backend has been written to help fix this; by similar measurements, it is consistently faster than Clang by 1.5-2x, and much faster than the Zig LLVM backend. While these numbers are nothing to scoff at, I believe there is more room for improvement, and I would like to see where it goes. Zig is a simpler language than C when comptime is not involved, and I would be excited to see that reflected in the benchmarks. It is also possible that Zig could use LLVM more efficiently, but I cannot comment on this without digging into the internals of the compiler.</p>
Of course, all of this is quite reasonable. The Zig compiler has had far, far fewer man-hours put into it, and this of course reflects in aspects of the compiler that simply take a lot of time, such as these. I look forward to seeing what can be done in the future.</p>
Tooling</h3>
Build system</h4>
The Zig build system is a little confusing. It is very neat to be able to write build system code in the language itself, and this is a feature I believe more languages should have. Unfortunately, it is as of current not well documented enough to justify its own complexity. This of course can be improved, and I hope it is.</p>
Language server</h4>
Zig currently does not have a "first class" language server. The "Zig Language Server", or ZLS, is unofficial; It does not have real compiler integration, so it is unfortunately limited in some ways. The creator of Zig apparently does not use a language server while programming, so I do slightly understand why it is not a priority, but I personally believe tools like a good language server are quite essential to wider/popular usage. Here are some quotes I have heard from people who have used it far more than I:</p>

"Deeply horrid"</li>
"It is one of the worst LSPs I have ever used"</li>
"Don't get me started"</li>
</ul>
Apparently it is very limited when comptime</code> comes into play, and cannot handle compound types like 2D arrays.</p>
I cannot offer much firsthand experience however.</p>
Debug mode</h3>
There are always more errors to be caught. I particularly recently noticed that Zig cannot currently catch use-after-realloc errors, like the following:</p>
const</span> std </span>= @</span>import</span>(</span>"std"</span>);
</span>
</span>pub </span>fn </span>main</span>() </span>!</span>void {
</span>    </span>const</span> allocator </span>=</span> std.heap.page_allocator;
</span>
</span>    var buffer </span>=</span> try allocator.</span>alloc</span>(</span>u8</span>, </span>4</span>);
</span>
</span>    buffer[</span>0</span>] </span>= </span>1</span>;
</span>    
</span>    </span>const</span> new_buffer </span>=</span> try allocator.</span>realloc</span>(buffer, </span>8</span>);
</span>    
</span>    </span>// Should be caught!
</span>    buffer[</span>0</span>] </span>= </span>99</span>; 
</span>
</span>    allocator.</span>free</span>(new_buffer);
</span>}
</span></code></pre>
Address sanitizer with Clang can catch this, so theoretically Zig should be able to catch it (perhaps with a similar system) too.</p>
Misc. Improvable things that won't be improved for reasons beyond me</h2>
Behavior around undefined</code></h3>
Debug mode</h4>
Apparently, it is desired that comparisons with undefined</code> panic. This seems reasonable to me. However, the issue for this has been open for almost ten years</a>, which makes me worry that it might be a while still until it is finished.</p>
This panics in Debug</code> and ReleaseSafe</code> modes, however, so it does at least work in some cases.</p>
pub </span>fn </span>main</span>() void {
</span>    </span>const</span> x: </span>u32 </span>=</span> undefined;
</span>    </span>if </span>(x </span>== </span>0</span>) {
</span>        </span>return </span>1</span>;
</span>    } </span>else </span>{
</span>        </span>return </span>0</span>;
</span>    }
</span>}
</span></code></pre>
Safety</h4>
According to this issue</a>, it is "not a goal of the Zig compiler" to catch issues like the following:</p>
pub </span>fn </span>main</span>() void {
</span>    var buf: []</span>u8 </span>=</span> undefined;
</span>    
</span>    </span>// Very not allowed!
</span>    buf[</span>0</span>] </span>= </span>1</span>;
</span>}
</span></code></pre>
This just seems silly to me. Catching something like this, in the simple case, should be just one pass over the AST; why not do it?</p>
Tabs and syntax</h3>
Zig simply doesn't allow tabs in comments and strings? This issue</a> explains more, but the justification of "it (a tab) is ambiguous (in) how it should be rendered", I do not quite agree with.</p>
Strings make some sense; you can still write \t</code> for a tab, and they do indeed make output ambiguous. However, they're still allowed in indentation! This means that in commenting out code, you can take a program from valid to invalid. zig fmt</code> does reify tabs into spaces, but if your editor is misconfigured and you're not running zig fmt</code> constantly?</p>
tabs.zig:5:36: error: comment contains invalid byte: '\t'
</span>//        const str: *const [1:0]u8 = "w";
</span>  ^~~~~~~~~~~
</span></code></pre>
Very odd.</p>
Similarly, the following will not compile:</p>
if </span>(a </span>>=</span>b) {
</span>    </span>...
</span>}
</span></code></pre>
because the whitespace isn't correct. Zig doesn't have warnings, so this is always a compile error.</p>
Iteration</h3>
Zig does not have a way to iterate through a slice or similar in any way except one-at-a-time forwards. Anything else? You're using a while</code> loop, and you'll enjoy it. Zig blanket bans proposals to change the language, so despite issues like this one</a>, I doubt this will happen any time soon.</p>
Warnings</h3>
Zig doesn't have 'em. Everything is an error. In practice, this mostly manifests through reasonably harmless things like "unused variable" notices becoming errors, which is reasonably annoying when just trying to spitball.</p>
My only note on the community</h2>
For the most part, the community is about par for the course for programming language communities; that is to say, quite nice. However, I have had some reasonably negative interactions that I feel are somewhat of a general trend. They usually proceed like the following:</p>

I ask a question about solving something in Zig. Often, given my background, it is about adapting my more functional-esque thinking to Zig.</li>
Someone chimes in with a half-solution that does not actually address my problem.</li>
I attempt to communicate this to them, which often involves explaining the features I would use in <insert other language>.</li>
They insist that these features are not needed, but do not elaborate on how one would solve the problem without them.</li>
</ol>
This is unpleasant, and while it's not a particularly uncommon thing to see in programming language communities, Zig seems to have a bit of a bad case of it. I suspect it is due to Zig's fairly minimalistic nature; it lacks a lot of features that one would otherwise use to solve problems. Of course, this is the appeal for many, but still. It is made worse when said topic is something one is particularly knowledgeable about, and the people you are conversing with believe they can solve the issue without that knowledge.</p>
I do not believe that a few bad apples necessarily spoil the whole barrel here, but they definitely sour it.</p>
Summary</h2>
I find Zig interesting, with an unfortunately negative connotation. I believe the goal of a C-like memory unsafe language "for the modern day", while interesting at first glance, ignores many of the issues that make C a problem in said modern day. Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. Alas, they are not; myself included.</p>
I believe that modern concerns of memory safety and correctness require modern solutions; not performing patchwork fixes over the core issue.</p>


Isabelle/HOL: The various rule methods
2025-09-19T00:00:00+00:00
The following is adapted from the Isabelle/HOL 2025 tutorial</a>, particularly 5.2 and onwards. It will explain much more thoroughly than I can.</p>
I also make no promise that the following is entirely 100% correct. It is ultimately my understanding, but I have run it past several others, and to the best of our knowledge it is correct.</p>
Notes</h1>
These rule methods can be used in many different ways. While some general principles are mentioned below, if the prerequisits are met,
every rule can theoretically be used with every rule method. Many of these various combinations will not be beneficial to proving a given
goal, and hence it is useful to know how the rule methods interact with rules and proof states in order to select the correct pairing.</p>
In that vein, the same rule will be interpreted differently by these different rule methods. Read more for how they work, and hence why.</p>
rule</code>, erule</code>, drule</code>, and frule</code>, informally</h1>
We use P</code>, Q</code>, and R</code> as arbitrary assumptions and goals throughout.</p>
rule</code></h2>
Consider the introduction rule conjI</code>:</p>
P   Q
</span>----- conjI
</span>P</span> ∧ </span>Q
</span></code></pre>
If we have a goal of form R ==> P ∧ Q</code>, from conjI</code> we can infer that it is sufficent to seperately prove P</code> and Q</code>. Indeed, performing apply (rule conjI)</code> on a goal of this shape will result in two goals:</p>
1</span>. </span>R </span>==> </span>P
</span>2</span>. </span>R </span>==> </span>Q
</span></code></pre>
which can be then proven seperately. rule</code> is for backwards-reasoning; here we can see that as moving "backwards up" the introduction rule (Starting with the bottom, and ending with the top.) It is therefore useful for introduction rules, as demonstrated.</p>
erule</code></h2>
erule</code> is designed to function with elimination rules. Take for example the elimination rule for disjunction:</p>
P</span> ∨ </span>Q</span>     (</span>P </span>==> </span>R</span>)    (</span>Q </span>==> </span>R</span>)
</span>-------------------------------- disjE
</span>              </span>R
</span></code></pre>
(Informally, to prove something about a disjunction, we must handle both possible cases.)</p>
If we have a goal of the form:</p>
P</span> ∨ </span>Q </span>==> </span>R
</span></code></pre>
we can perform apply (erule disjE)</code> to transform this into two goals:</p>
1</span>. </span>P </span>==> </span>R
</span>2</span>. </span>Q </span>==> </span>R
</span></code></pre>
where we must handle each possible case of the disjunction. erule</code> is a bit of both backwards and forwards reasoning. In the above elimination rule, we can see that we need three assumptions to prove R</code> --- we already have P ∨ Q</code>, so it is sufficient to then only additionally prove P ==> R</code> and Q ==> R</code>, which are exactly the goals erule</code> gives us.</p>
Notable: erule</code> deletes the already-held assumption, as it is "rarely useful" (quoting the Isabelle/HOL tutorial). See below's note for more.</p>
Note on rule</code> vs erule</code></h2>
As mentioned, erule</code> deliberately deletes the already-held assumptions when using an elimination rule. Above, we could see that P ∨ Q</code> was not present in the generated goals, as it was already assumed. By instead using rule</code>, we can keep the original goal in our assumptions as follows. If we apply the principles from the rule</code> section to disjE</code>, we would get:</p>
P</span> ∨ </span>Q </span>==> </span>R
</span>
</span>apply (rule disjE)
</span>
</span>⟦ </span>P</span> ∨ </span>Q</span> ⟧ </span>==> </span>P</span> ∨ </span>Q
</span>⟦ </span>P</span> ∨ </span>Q</span>; </span>P</span> ⟧ </span>==> </span>R
</span>⟦ </span>P</span> ∨ </span>Q</span>; </span>Q</span> ⟧ </span>==> </span>R
</span></code></pre>
i.e., rule</code>, as expected, replaces the goal R with the goals sufficent to prove it. In this case, however, the first goal is trivial, and in the latter two, P ∨ Q</code> holds little worth, as we know either P</code> or Q</code>. This is why erule</code> automatically discharges the first goal and deletes the already-held assumption.</p>
drule</code></h2>
For the sake of example, recall (one of) the conjunction elimination rules:</p>
P</span> ∧ </span>Q
</span>----- conjunct1
</span>  </span>P
</span></code></pre>
This rule is more specifically called a "destruction" rule, as it takes apart (destroys) the original term (here the conjunction) and concludes with one of its subterms. The d</code> in drule</code> therefore stands for destruction</code> or destroy</code>. Destruction rules are used for forwards-reasoning, as you move "forwards down" the rule.</p>
apply (drule conjunct1)</code> hence replaces an assumption of form P ∧ Q</code> with one of P</code>, deleting the original P ∧ Q</code> assumption.</p>
P</span> ∧ </span>Q </span>==> </span>R
</span>
</span>apply (drule conjunct1)
</span>
</span>P </span>==> </span>R
</span></code></pre>
frule</code></h2>
frule</code> functions the same as drule</code>, but does not delete the original premise. The f</code> stands for forwards</code>, as it is used for forwards-reasoning.</p>
P</span> ∧ </span>Q </span>==> </span>R
</span>
</span>apply (frule conjunct1)
</span>
</span>⟦ </span>P</span> ∧ </span>Q</span>; </span>P</span> ⟧ </span>==> </span>R
</span></code></pre>
Useful related tools</h2>
For all the above rule methods, [of P₁ P₂ ... Pₙ]</code> can be used to explicitly instantiate them instead of using the rule_tac</code> family (which is explained below). This instantiates left-to-right by occurence, so with</p>
thm conjI (* ⟦</span>?</span>P</span>; </span>?</span>Q</span>⟧ </span>==> ?</span>P</span> ∧ </span>?</span>Q</span> *)
</span></code></pre>
conjI [of A B]</code> will result in the instantiation ⟦A; B⟧ ==> A ∧ B</code>, from where the rule will proceed.</p>
R </span>==> </span>A</span> ∧ </span>B
</span>
</span>Isabelle</span> can solve this on its own, but for the sake </span>of</span> example</span>.
</span>apply (rule conjI [</span>of </span>A B</span>])
</span>
</span>1</span>. </span>R </span>==> </span>A
</span>2</span>. </span>R </span>==> </span>B
</span></code></pre>
Notably, [of ...]</code> does still work with the _tac</code> family, but there is (as far as I know) no reason to use it over _tac</code>'s explicit instantiation. Speaking of:</p>
The _tac</code> suffixes</h2>
For each of the above,  there is a corresponding _tac</code> (standing for tactic): rule_tac</code>, drule_tac</code>, etc. These _tac</code>s are slightly more powerful than their _tac</code>less equivalents. Firstly, each allows for the various premises to be explicitly instantiated by name. For example, with the conjI</code> rule, one could explicitly write</p>
thm conjI (* ⟦</span>?</span>P</span>; </span>?</span>Q</span>⟧ </span>==> ?</span>P</span> ∧ </span>?</span>Q</span> *)
</span>
</span>R </span>==> </span>A</span> ⋀ </span>B
</span>
</span>apply (rule_tac </span>P</span>=</span>A</span> and </span>Q</span>=</span>B </span>in</span> conjI)
</span>
</span>1</span>. </span>R </span>==> </span>A
</span>2</span>. </span>R </span>==> </span>B
</span></code></pre>
This allows the rule to refer to meta-forall-bound variables, which most commonly arise when performing induction or similar. For a goal of form:</p>
P</span> n
</span></code></pre>
with some n :: nat</code> mentioned in P</code>, performing apply (induction n)</code> will generate the goals</p>
P 0 
</span>⋀ nat</span>. </span>P</span> nat </span>==> </span>P</span> (</span>Suc</span> nat) (* </span>Variable</span> naming may differ</span>.</span> *)
</span></code></pre>
nat</code> is a meta-forall bound variable. This functions as expected; during the induction step of an inductive proof, we must prove that for any nat</code>, P nat ==> P (Suc nat)</code>. Because it is meta-forall bound, rule</code> and friends cannot refer to nat</code> directly using [of ...]</code> (Although, automatic unification can work). Instead, we must use rule_tac</code> and friends to refer to it. I am not quite sure why this is, but I presume it is due to internal complexities around the meta-forall.</p>
A small artificial example of this difference, if the above is not clear.</summary>
Recall that [of ...]</code> can be used to explicitly instantiate:</p>
lemma without_forall</span>: </span>"A ∧ B ==> A"
</span>  apply (erule conjE [</span>of </span>A</span>]) (* succeeds *)
</span>
</span>lemma with_forall</span>: </span>"⋀ a b. a ∧ b ==> a"
</span>  apply (erule conjE [</span>of</span> a]) (* fails *)
</span>  apply (erule_tac </span>P</span>=</span>a </span>in</span> conjE) (* succeeds *)
</span></code></pre>
These lemmas are otherwise equivalent; only their presentation differs.</p>
</details>
In general, these _tac</code> methods have the form</p>
rule_tac v₁ </span>=</span> t₁ and v₂ </span>=</span> t₂ and </span>...</span> and vₙ </span>=</span> tₙ </span>in </span>RULE
</span></code></pre>
where vₙ</code> is a variable occuring in RULE</code>, and tₙ</code> is a locally bound variable or assumption. Any combination of zero or more of the variables occuring in RULE</code> may be used, in any order.</p>
The _tac</code> methods have an additional advantage, which is that they can be told to refer to a specific goal. If we have goals of the form</p>
1</span>. </span>A</span> ∧ </span>B </span>==> </span>R
</span>2</span>. </span>P</span> ∧ </span>Q </span>==> </span>R
</span></code></pre>
erule conjE</code> and friends will by default refer to the first goal. Using erule_tac [i] conjE</code>, we can refer to the ith</code> goal (1-indexed.) When combining this with specifying variables, the goal specifier comes first. (i.e., apply (erule_tac [1] P=a in conjE)</code>.)</p>
rule</code>, erule</code>, drule</code>, and frule</code>, (more) formally</h1>
This section is almost entirely copied from the aformentioned Isabelle/HOL tutorial.</p>
Given an arbitrary rule R of the form:</p>
P</span>₁ </span>P</span>₂ </span>... </span>Pₙ
</span>------------  R
</span>      </span>Q
</span></code></pre>
For elimination rules, P₁</code> is referred to as the "Major premise". This will usually be the object being eliminated. In disjE</code> for example, it is P ∨ Q</code>.</p>


Method rule</code> unifies Q</code> with the current subgoal, and replaces it with the n</code> subgoals P₁ ... Pₙ</code>.</p>
</li>

Method erule</code> unifies Q</code> with the current subgoal, and P₁</code> with the first suitable assumption. The subgoal is then replaced with the n - 1</code> subgoals P₂ ... Pₙ</code>, and the assumption P₁</code> is deleted.</p>
</li>

Method drule</code> unifies P₁</code> with the first suitable assumption, which it then deletes. It then adds the n - 1</code> subgoals P₂ ... Pₙ</code>, and the original subgoal gains the assumption Q</code>.</p>
</li>

Method frule</code> is like drule</code>, but it does not delete P₁</code>.</p>
</li>
</ol>


Crafting a dependent typechecker, part 1
2025-07-19T00:00:00+00:00
This series is intended to give an interested layperson some idea of what goes on behind-the-scenes in a dependent typechecker, and how they might implement one of their own.</p>
I personally hold the belief that dependent languages (or similar) will eventually be the future of programming, so knowing this information seems worthwhile to me. One may also simply be interested for the sake of it, or may be interested in implementing their own dependent language.</p>
This series does assume a small base amount of knowledge around dependent programming languages. There are many tutorials out there far better than I could provide, so I will refer the reader to the wider internet if they are curious. (Return here afterwards, though!).</p>
Additionally, the code snippets will be in OCaml, although a Haskell or Rust version may be made available at a later date.</p>
The technique we will implement in this series can most succinctly be described as "Bidirectional typechecking, utilizing Normalization by Evaluation". I do not expect the reader to understand that sentence for at least a little while ;).</p>
All code snippets will be collated at the end of each page, so scroll all the way down if you're only interested in that.</p>
Resources</h2>
The following are resources I highly recommend for exploring this topic on your own.</p>

András Kovacs' "Elaboration Zoo", found here</a>. It was a primary source of inspiration for this series.</li>
"A tutorial implementation of a dependently typed lambda calculus", by Andres Löh, Conor McBride, and Wouter Swierstra; found here</a>.</li>
"Checking Dependent Types with Normalization by Evaluation: A Tutorial", by David Christiansen, found here</a>, for the more lisp-minded.</li>
</ul>
The fundamental operation of typechecking</h2>
If you have implemented a typechecker before, you may have come to the realization that deciding when two things are the same is a very large component of typechecking. Whether it be simply checking that two arguments to +</code> are both integers, or larger problems with polymorphism, the arguable core of typechecking is deciding equality.</p>
In a dependent language, our types can (and often do) contain expressions that must be evaluated. Therefore, in order to explore how we check equality in the presence of evaluation, we will first start by considering how we do this for a very simple language - integer arithmetic. Take two expressions:</p>
1</span>: </span>17 </span>* </span>2 </span>+ </span>4 </span>- </span>2
</span>2</span>: </span>7</span>^</span>2 </span>- </span>4 </span>* </span>4 </span>+ </span>3
</span></code></pre>
How might we decide whether these are equal? The obvious solution is to evaluate them. Indeed, (sparing the reader the derivation), we can see they both evaluate to 36</code>, and so they are equal.</p>
Let us now introduce a small extension: Variables with a known value, using "let". We will refer to the variables themselves as "bound variables", as they are bound by the "let". In this case, they are additionally bound to a value. Terms containing only bound variables are referred to "closed" terms - this alludes to, for example, closed and open systems in the real world. Getting back to evaluation, we could simply substitute the computed value:</p>
let </span>x </span>= </span>8</span>^</span>2 </span>- </span>3</span>;
</span>
</span>1</span>: x </span>* </span>2 </span>- </span>5
</span>2</span>: </span>13 </span>* </span>39
</span>
</span>substitute</span>...
</span>
</span>1</span>: (</span>8</span>^</span>2 </span>- </span>3</span>) </span>* </span>2 </span>- </span>5
</span>2</span>: </span>13 </span>* </span>39
</span></code></pre>
And then evaluate. (In this case, our result is 117.) However, what if the variable occurs multiple times? The following is a little bad, but not awful:</p>
let </span>x </span>= </span>8</span>^</span>2 </span>- </span>3</span>;
</span>
</span>1</span>: x </span>* </span>2 </span>- </span>x</span>^</span>2 </span>+ </span>5
</span>
</span>substitute</span>...
</span>
</span>1</span>: (</span>8</span>^</span>2 </span>- </span>3</span>) </span>* </span>2 </span>- </span>(</span>8</span>^</span>2 </span>- </span>3</span>)</span>^</span>2 </span>+ </span>5
</span></code></pre>
But what if x</code> was the following?</p>
let </span>x </span>= </span>8 </span>^ </span>2 </span>- </span>3 </span>+ </span>(</span>14 </span>* </span>2 </span>- </span>4</span>) </span>+ </span>8 </span>- </span>(</span>14 </span>^ </span>2</span>) </span>* </span>3 </span>+ </span>5 </span>* </span>5 </span>- </span>18 </span>^ </span>3 </span>+ </span>5 </span>* </span>6 </span>- </span>12 </span>* </span>4 </span>* </span>(</span>6 </span>^ </span>2</span>) </span>+ </span>(</span>8</span>^</span>2 </span>- </span>3</span>) </span>* </span>2 </span>- </span>18 </span>* </span>14 </span>^ </span>3 </span>- </span>2 </span>* </span>(</span>4 </span>- </span>3 </span>^ </span>2</span>) </span>+ </span>12 </span>* </span>18 </span>- </span>3</span>^</span>4 </span>+ </span>1
</span></code></pre>
Duplicating that would clearly not be ideal!</p>
Perhaps we could compute x</code> in advance, and then substitute that result in. This is much better:</p>
let </span>x </span>= </span>8</span>^</span>2 </span>- </span>3</span>;
</span>
</span>evaluate and substitute</span>...
</span>
</span>let </span>x </span>= </span>61</span>;
</span>
</span>1</span>: </span>61 </span>* </span>2 </span>- </span>61</span>^</span>2 </span>+ </span>5
</span></code></pre>
(In fact, there is yet another optimization to do: What if we don't need to compute it at all, say because it's not used? We will explore this possibility later.)</p>
A simple OCaml interpretation of the terms of this language may be the following.
(sidetrack: A "term" is some element of a language. Above, we have the language of (restricted) integer arithmetic, and our terms are expressions of said. Hence, we call our OCaml interpretation of this language term</code>.)</p>
type </span>variable </span>= </span>string
</span>
</span>type </span>term </span>=
</span>    | Literal </span>of </span>int 
</span>    | Name </span>of </span>variable 
</span>    | Mul </span>of </span>term </span>* </span>term 
</span>    | Exp </span>of </span>term </span>* </span>term 
</span>    | Add </span>of </span>term </span>* </span>term 
</span>    | Sub </span>of </span>term </span>* </span>term 
</span>    | Let </span>of </span>variable </span>* </span>term </span>* </span>term 
</span>      </span>(* let x = ...; ... *)
</span></code></pre>
We then must make an environment that associates, or "binds", our names to terms. Let</code> is often called a "binder" because it functions as the source of this binding. We will make our context a list of pairs (variable name, term)</code>, and will reimpliement the lookup function for example's sake, although a suitable function is available as List.assoc</code>.</p>
type </span>environment </span>= (</span>variable </span>* </span>term</span>) </span>list
</span>
</span>let rec </span>lookup </span>(</span>env </span>: environment</span>) (</span>name </span>: variable</span>) : </span>term </span>=
</span>    </span>match</span> env </span>with
</span>    </span>(* See note below. *)
</span>    </span>| </span>[] </span>-> failwith (</span>"Variable " </span>^</span> name </span>^ </span>" not found."</span>)
</span>    </span>| </span>(</span>nm</span>, </span>value</span>) :: </span>rest </span>->
</span>        </span>if</span> nm </span>=</span> name </span>then
</span>            value
</span>        </span>else
</span>            lookup rest name
</span></code></pre>
Note: In this series, we will not be considering the possibility that a name is used without being previously defined in some way. This is an error, and can be handled via normal means, e.g. a suitable error message.</p>
We now note something curious: Our lookup function need not return a fully computed value! It could return 7 + 2</code>, which we would have to further evaluate before we could do anything with. It would be possible of course to manually insert invariants ensuring that this is not the case, but we could still accidentally violate them.</p>
Here we hit one of the most important distinctions in our exploration of dependent typechecking.</p>
Terms vs. Values</h2>
A "term", as previously seen, is any element of a chosen language. Above, this was (some subset of) integer arithmetic. We could also consider the language of OCaml programs, of which the above examples would be terms. However, two terms are not always easy to compare. We may need to evaluate one, or both, and we don't know whether that will be needed until we start comparing them.</p>
Instead, what if we defined another type that was guaranteed to be reduced to some suitable level? For this simple case, we could restrict this to contain only fully evaluated terms (i.e., integers). We'll call these "values".</p>
type </span>value </span>=
</span>    | VLiteral </span>of </span>int
</span></code></pre>
We prefix these constructors with V</code> to ensure they're distinct, and to remind us that they construct values. Then, we could modify our environment and lookup function to only deal with values:</p>
- type</span> environment </span>= </span>(variable </span>*</span> term) </span>list
</span>+ type</span> environment </span>= </span>(variable </span>*</span> value) </span>list
</span>
</span>- let rec </span>lookup </span>(</span>env </span>: environment</span>) (</span>name </span>: variable</span>) : </span>term </span>=
</span>+ let rec </span>lookup </span>(</span>env </span>: environment</span>) (</span>name </span>: variable</span>) : </span>value </span>=
</span></code></pre>
and now we know that lookup</code> will always return something we can handle immediately, with no further processing.</p>
In the general case, we call this "suitably-reduced" constraint a "normal form". We can say that value</code> contains only elements of term</code> in this chosen normal form.</p>
Now we can finish our little evaluator. We do a slight hack to perform arithmetic inside values; if our value type contained more than just the constructor VLiteral</code>, we would have to consider how to handle that case. This is something we will cover soon.</p>
(* OCaml does not have integer exponentiation by default. Definition omitted. *)
</span>let </span>pow </span>(</span>a </span>: int</span>) (</span>b </span>: int</span>) : </span>int </span>=</span> ...
</span>
</span>let rec </span>do_op </span>(</span>op </span>: int -> int -> int</span>) (</span>a </span>: value</span>) (</span>b </span>: value</span>) : </span>value </span>=
</span>    </span>(* Hack: This is only valid because we know our value type has one constructor, VLiteral. *)
</span>    </span>let </span>VLiteral va </span>=</span> a </span>in
</span>    </span>let </span>VLiteral vb </span>=</span> b </span>in
</span>    VLiteral (op va vb)
</span>    
</span>let rec </span>eval </span>(</span>env </span>: environment</span>) (</span>tm </span>: term</span>) : </span>value </span>=
</span>    </span>match</span> tm </span>with
</span>    </span>| </span>Literal </span>i </span>-> VLiteral i
</span>    </span>| </span>Name </span>nm </span>-> lookup env nm
</span>    </span>| </span>Mul (</span>a</span>, </span>b</span>) -> do_op ( </span>*</span> ) (eval env a) (eval env b)
</span>    </span>| </span>Exp (</span>a</span>, </span>b</span>) -> do_op pow   (eval env a) (eval env b)
</span>    </span>| </span>Add (</span>a</span>, </span>b</span>) -> do_op ( </span>+</span> ) (eval env a) (eval env b)
</span>    </span>| </span>Sub (</span>a</span>, </span>b</span>) -> do_op ( </span>-</span> ) (eval env a) (eval env b)
</span>    </span>| </span>Let (</span>nm</span>, </span>def</span>, </span>rest</span>) ->
</span>        </span>let </span>result </span>=</span> eval env def </span>in
</span>        </span>let </span>new_env </span>= </span>(nm, result) :: env </span>in
</span>        eval new_env rest
</span></code></pre>
In the Let</code> case, we compute the definition first, then extend our environment with the new name and value before computing the rest of the expression.</p>
We then, by returning a value</code>, have a guarantee that whatever comes out of eval</code> is as simple as we want it to be.</p>
Comparing for equality is then very simple: We use eval</code> to evaluate our terms into values, then because our values are in a nice normal form, we have the guarantee that we can compare them easily, with no further evaluation needed.</p>
Wrap up</h2>
So far we have covered:</p>

Languages and terms.</li>
Simple evaluation strategies for let bound variables & closed terms.</li>
Values and normal forms.</li>
</ol>
In the next part, we will explore how to take these concepts and apply them to something much closer to a "real" programming language, with lambda</code> expressions and application, which will require the introduction of a "closure". From there, we can explore how to deal with open terms, containing free variables, and onwards to dependent types.</p>
Code</h2>

type </span>variable </span>= </span>string
</span>
</span>type </span>term </span>=
</span>    | Literal </span>of </span>int 
</span>    | Name </span>of </span>variable 
</span>    | Mul </span>of </span>term </span>* </span>term 
</span>    | Exp </span>of </span>term </span>* </span>term 
</span>    | Add </span>of </span>term </span>* </span>term 
</span>    | Sub </span>of </span>term </span>* </span>term 
</span>    | Let </span>of </span>variable </span>* </span>term </span>* </span>term 
</span>      </span>(* let x = ...; ...*)
</span>      
</span>type </span>value </span>=
</span>    | VLiteral </span>of </span>int
</span>      
</span>type </span>environment </span>= (</span>variable </span>* </span>value</span>) </span>list
</span>
</span>let rec </span>lookup </span>(</span>env </span>: environment</span>) (</span>name </span>: variable</span>) : </span>value </span>=
</span>    </span>match</span> env </span>with
</span>    </span>(* See note below. *)
</span>    </span>| </span>[] </span>-> failwith (</span>"Variable " </span>^</span> name </span>^ </span>" not found."</span>)
</span>    </span>| </span>(</span>nm</span>, </span>value</span>) :: </span>rest </span>->
</span>        </span>if</span> nm </span>=</span> name </span>then
</span>            value
</span>        </span>else
</span>            lookup rest name
</span>      
</span>(* OCaml does not have integer exponentiation by default. Definition omitted. *)
</span>let </span>pow </span>(</span>a </span>: int</span>) (</span>b </span>: int</span>) : </span>int </span>=</span> ...
</span>
</span>let rec </span>do_op </span>(</span>op </span>: int -> int -> int</span>) (</span>a </span>: value</span>) (</span>b </span>: value</span>) : </span>value </span>=
</span>    </span>(* Hack: This is only valid because we know our value type has one constructor, VLiteral. *)
</span>    </span>let </span>VLiteral va </span>=</span> a </span>in
</span>    </span>let </span>VLiteral vb </span>=</span> b </span>in
</span>    VLiteral (op va vb)
</span>    
</span>let rec </span>eval </span>(</span>env </span>: environment</span>) (</span>tm </span>: term</span>) : </span>value </span>=
</span>    </span>match</span> tm </span>with
</span>    </span>| </span>Literal </span>i </span>-> VLiteral i
</span>    </span>| </span>Name </span>nm </span>-> lookup env nm
</span>    </span>| </span>Mul (</span>a</span>, </span>b</span>) -> do_op ( </span>*</span> ) (eval env a) (eval env b)
</span>    </span>| </span>Exp (</span>a</span>, </span>b</span>) -> do_op pow   (eval env a) (eval env b)
</span>    </span>| </span>Add (</span>a</span>, </span>b</span>) -> do_op ( </span>+</span> ) (eval env a) (eval env b)
</span>    </span>| </span>Sub (</span>a</span>, </span>b</span>) -> do_op ( </span>-</span> ) (eval env a) (eval env b)
</span>    </span>| </span>Let (</span>nm</span>, </span>def</span>, </span>rest</span>) ->
</span>        </span>let </span>result </span>=</span> eval env def </span>in
</span>        </span>let </span>new_env </span>= </span>(nm, result) :: env </span>in
</span>        eval new_env rest
</span></code></pre>
</details>


Debruijn indexes and levels, and why they're handy
2025-05-26T00:00:00+00:00

Ideological differences</h2>

Philosophy</h3>
At one point, this part of the article contained a runthrough of the `zig zen</code>, and my opinions on each bullet point. I have decided that that is not a constructive discussion of Zig. It suffices for me to say that I do not believe Zig particularly embodies its own zen.</p>`

Tooling</h3>

Misc. Improvable things that won't be improved for reasons beyond me</h2>

Blueberry Wren Thoughts

Flat/Non-higher-order construction of ANF via mutable holes

Type safe interpreters

Axiom J in Homotopy Type Theory (HoTT)

Preface</h2>
Happy new years!</p>

Notation</h3>
`∀</code> may be used in place of a Pi-type in some cases. A nested Π (a b : A). ...</code> (or sim. for Σ</code>) represents Π (a : A). Π (b : A). ...</code>.</p>`

Written in Pure Sea

Horrible answers to "What is a type?"

Opinion piece: On Zig (and the design choices within)

Isabelle/HOL: The various rule methods

Crafting a dependent typechecker, part 1

Debruijn indexes and levels, and why they're handy

Blueberry Wren Thoughts

Flat/Non-higher-order construction of ANF via mutable holes

Type safe interpreters

Examples</h2> Now let's look at some examples and their types.</p>

Axiom J in Homotopy Type Theory (HoTT)

Preface</h2> Happy new years!</p>

Notation</h3> ∀</code> may be used in place of a Pi-type in some cases. A nested Π (a b : A). ...</code> (or sim. for Σ</code>) represents Π (a : A). Π (b : A). ...</code>.</p>

Written in Pure Sea

Horrible answers to "What is a type?"

Opinion piece: On Zig (and the design choices within)

Ideological differences</h2>

Philosophy</h3> At one point, this part of the article contained a runthrough of the zig zen</code>, and my opinions on each bullet point. I have decided that that is not a constructive discussion of Zig. It suffices for me to say that I do not believe Zig particularly embodies its own zen.</p>

Tooling</h3>

Misc. Improvable things that won't be improved for reasons beyond me</h2>

Isabelle/HOL: The various rule methods

Crafting a dependent typechecker, part 1

Resources</h2> The following are resources I highly recommend for exploring this topic on your own.</p>

Debruijn indexes and levels, and why they're handy

Preface</h2>
Happy new years!</p>

Notation</h3>
`∀</code> may be used in place of a Pi-type in some cases. A nested Π (a b : A). ...</code> (or sim. for Σ</code>) represents Π (a : A). Π (b : A). ...</code>.</p>`

Philosophy</h3>
At one point, this part of the article contained a runthrough of the `zig zen</code>, and my opinions on each bullet point. I have decided that that is not a constructive discussion of Zig. It suffices for me to say that I do not believe Zig particularly embodies its own zen.</p>`