Mere in the Browser: Where Everything Converges

The self-hosted compiler exists in Mere and can emit itself. Everything in this part was built to run somewhere a person could actually reach it, and each piece was wired into a web page the moment it landed. This closing episode is about those pages — four of them — and about the fact that reaching them required no new invention at all. They are the point where every part of this series pays its dividend at once.

Four pages

Each self-hosted component became a live page, in the order it was built. There is a formatter page: paste Mere source, and it comes back cleanly formatted. A REPL page: paste an expression, and it runs and shows the result. A type checker page: paste code, and it shows the type inferred for it. And a compiler page: paste Mere source, and it hands back the text of a WebAssembly module — the browser equivalent of running the compiler on a file, with no file and no server involved.

All four run the same way. They are the self-hosted lexer, parser, formatter, evaluator, type checker, and code generator — the Mere programs of the previous five episodes — compiled to WebAssembly and loaded into a page. No OCaml is present; no request leaves the browser. The Mere pipeline, compiled to the sandbox it was designed to reach, does its work locally in a tab.

Nothing here is new

The striking thing about these pages is how little of them is a new capability. They are the convergence of parts that were each built, in their own time, for their own reasons.

The Wasm backend from Part IV is what compiles the self-hosted pipeline to something a browser can load — the sandbox target, chosen back then partly because this was where it would lead. The sandbox model is why the pipeline can run untrusted-by-default in a page and reach the outside only through granted imports. The foreign function interface from earlier in Part IV — opaque handles for DOM elements, strings marshaled across the boundary, event handlers passed as function-table indices — is the glue that connects the compiled Mere to the text box you type into and the panel where the result appears. And the self-hosted pipeline of Part V is the thing being run. Put those together and you get a compiler on a web page; each was necessary, and not one of them was built here. This episode is assembly, not construction, which is exactly what a well-built series of parts should make possible at the end.

Real programs, not toy expressions

What runs through these pages is not limited to one-liners. Real programs go end to end through the self-hosted compiler in the browser: a FizzBuzz, a quicksort sorting a list, a JSON renderer, a Brainfuck interpreter, a regular-expression engine. That last pair is worth savoring — a Brainfuck interpreter is itself a small language implementation, so the browser is running an interpreter that was compiled by a compiler that was written in the language it compiles. The tower of self-reference that was abstract in the meta-circular and bootstrap episodes becomes concrete and clickable here: you paste, and a Mere compiler — itself compiled from Mere — turns your program into Wasm in front of you.

It is worth keeping the honest scope in view, as the coverage ledger would insist. The pipeline that runs in these pages is the classical functional core of Mere — parse, Hindley–Milner types, evaluation, and code generation for that core. The analyses that make Mere distinctive — the borrow modes, the regions, the effect system — are still checked by the OCaml reference, not yet self-hosted. The pages run the heart of the language, self-hosted and byte-verified; they do not yet run all of it, and saying which is which is part of telling the story straight.

The end of the technical arc

With this, the technical spine of the series is complete. Across five parts the language acquired a philosophy and a minimal core, an explicit memory model, an explicit effect system, code generation to four backends held in exact agreement, and finally a compiler written in itself and running in a browser. It reads, checks, runs, and compiles its own source — and it does the last of those in front of you, on a page you can open. The claim that motivated the docs site and the whole self-host effort — that Mere is a language you can actually build in — is now something you can click rather than something to take on faith.

What remains of the story is not more machinery but a passage into the world. A language that works is not yet a language anyone uses; it needs a name that means something, a place to live, an identity. The next part is about that crossing — what the language ended up being called, and what it took to stop being a private experiment and become a public thing. Next, Part VI opens: the name “Mere,” and going public.