Changelog (mere)

Major implementation milestones recorded per-slice (newest first). See git log for detailed commit messages.

v0.1.626 — 2026-10-07

_On -rv / -rv64, two syntax errors -- or two imports that resolve nowhere -- are reported at the program's own lines again, not at the RISC-V prelude's._

mere -rv64 of a tree whose .mere_modules had not been installed answered

parse error: import: cannot resolve path `mgz/inflate.mere` ...
    --> <rv-prelude>:312:1

with the prelude's line 312 printed under it; -c said main.mere:312:1. When the parse fails, the report parses the program again on its own, with recovery, to list every error. Those positions are the file's own lines -- no prelude is in front of it, and an import is resolved before the prelude is glued on -- but on the RISC-V paths they were read as if they counted from the top of the prelude, and moved into it. v0.1.604 fixed the same thing for type errors; the parse's report kept it. A lone error was right, because it was reported at the first parse's position, which does count from the prelude; it now takes the re-parse's, which is the same line.

scripts/rv_prelude_check.sh compiles three programs (two syntax errors, one unresolvable import, two of them) with -c and -rv and requires the same --> lines; against v0.1.625 the first and the third fail.

v0.1.625 — 2026-10-07

_A signal a program wants to hear about: proc_sig_catch installs a handler that only marks it, proc_sig_take takes the marks where the program can act on them, and proc_sig_ignore is SIG_IGN. For mere-ruby, whose trap answered only Process.kill to itself and died of a SIGUSR1 sent from outside._

mere-ruby's Signal.trap wrote the handler into a table and installed nothing, so a signal from another process took the default action: trap(:USR1) { ... } and then kill -USR1 from outside ended it (exit 158), where ruby runs the handler on its main thread. CRuby's test_process waits for a child ruby to print from a trap while it sits in system; the child died, its cat kept the pipe, and the whole file hung (mere-ruby note 290).

A handler may do almost nothing, and an interpreter's handler code is anything but nothing. So the handler marks the signal (a sig_atomic_t per number and one that says some mark is up) and returns; the program asks at a point of its own -- an interpreter at a statement boundary -- and does there what the handler could not.

• proc_sig_catch sig keep -- SA_RESTART, so a blocking call resumes and the

mark waits for the next ask. keep = 1 is ruby's rule for the signals it handles by default: an ignored disposition inherited from the parent (nohup's SIGHUP) is put back and kept. 0 installed, 1 kept, -1 refused (EINVAL for a number out of range, in proc_last_errno).

• proc_sig_take () -- the lowest marked signal, its mark taken down; 0 when

none. Two arrivals before a take are one mark, as two pending signals are one in the kernel.

• proc_sig_ignore sig -- SIG_IGN, inherited across exec(2), which is what

ruby's trap(sig, "IGNORE") gives a child.

C only, like the rest of the proc_sig_* family; the other backends refuse the extern by name. scripts/procsig_check.sh grows from 22 rows to 50: the marking handler from the default (a mark from raise, from another process, two arrivals as one, the lower number first, a child starting with the default, an unknown number refused) and under an inherited SIG_IGN for SIGHUP (keep = 1 kept, keep = 0 catches). Two poisons (a take that leaves the mark up, a keep that is not honoured) each fail it. Run once on the CI image (Linux x86-64, gcc -O0 and -O2, dash): 50/50.

v0.1.624 — 2026-10-06

_RISC-V gives back what a compaction frees while coroutines exist, keeping only blocks a stopped stack can reach -- C's pins. mere-ruby's real Fibers (its collector runs on a coroutine of its own) now run corpus 165 and 213 on RV64. And sleep_ms exists there._

v0.1.623 reused no arena block while any coroutine existed. mere-ruby collects on a coroutine of its own, so every collection's frees were kept for good, and with its Fiber layer on RV (m_fiber_coro in place of the one that runs a fiber to completion) corpus 165 ran out of memory in its first collection. Now:

• A block handed back while coroutines exist waits on a retired list. After a

compaction builtin, or at a region block's exit, once a megabyte has been retired since the last time, the prelude's rvcoro_release walks every stopped stack -- the walk coro_scan_ints makes, three hops and the stack's own region values -- and gives back the blocks none of them reaches; the rest wait for the next time (not counted again, so a stack that pins a megabyte does not make every block exit a release).

• The walk allocates nothing: a Map and a Vec per walk were garbage inside

mere-ruby's collector. Its visited set is an open-addressing table kept across walks (stamped, so nothing is cleared) and its work list a reused array.

• A stack's "own region values" run from its innermost open block's mark to

where the heap stood when it stopped -- not to the heap's current top, which for mere-ruby's main stack, stopped while the collector ran, took in all of the collector's tables. A release's walk is capped (65,536 addresses); one that reaches the cap keeps every block, as before.

• coro_scan_ints calls f after its walk, as C does: called from inside it,

mere-ruby's collector code exited region blocks, whose release started a second walk over the first one's state.

• sleep_ms waits on the clock (there is no sleep to ask the emulator for);

mere-ruby's Fiber scheduler sleeps.

Measured with mere-ruby 528bdd6 on RV64 at 256 MB, its Fiber layer in place: corpus 213, 220, 231, 233 and 237 agree with ruby (they did not with the layer that runs a fiber to completion), and 165 still does (34 s → 44 s). 214, 219 and 235 switch fibers every few statements and still run out of memory: every switch raises the high-water mark, so on one bump heap shared by every stack no region block's rollback reaches past it. Giving each stack an allocation area of its own is the next step.

compact_reuse now churns past a megabyte so that the release runs, and coro_check poisons it (RV 9: the release gives back a block a stopped stack reaches -- the held string is overwritten).

v0.1.623 — 2026-10-06

_RISC-V has coroutines: coro_new, coro_new_sized, coro_transfer, coro_switch, coro_exit, coro_root and coro_scan_ints, on both widths. Every coroutine runs in one region of RAM and a switch copies stacks in and out of it, so ten thousand suspended coroutines fit in a few megabytes._

The RV backend refused coroutines by name: "the bare-metal runtime has one stack and nowhere to map another". It still has no virtual memory, so a stack per coroutine would be a fixed reservation of real RAM -- and test/coro/many.mere keeps ten thousand suspended while sized_reuse recurses twenty thousand deep in one. So the stacks are COPIED instead:

• Every coroutine runs with its stack ending at the same address, in a region of

its own. __rv_cswap saves ra, s0 and s1..s11 on the stack being left, writes that stack's live part out to a buffer kept with the coroutine, writes the one being entered back to the same addresses, and restores. Nothing that points into a stack (a saved fp, a try_or record) ever moves. The main stack is not copied. A coroutine that has never run holds a seeded frame whose return address is __rv_coro_boot.

• The rest of the runtime is the RV prelude's, in Mere (rvcoro_): a table of

records with a free list, generational handles (a stale handle to a reused slot is told apart, as C's are), the checks and messages the C backend gives (finished, not the running coroutine, a body that hands over to itself), and what each stack carries across a switch -- its try_or record, its region depth and block marks. It is written on a few new internal primitives (raw words, the runtime's words, the switch, the layout).

• Layout. A program that makes or switches to a coroutine gives a sixteenth

of RAM (at least 256 KiB) to the main stack and the region below it to the coroutines -- a sixteenth too, or --coro-stack <MB> (refused if the heap would be left less than an eighth). An eighth each was the first choice; mere-ruby's corpus 213 needed the heap back. The heap's limit is kept in tp, which this backend did not use, so the allocation check is still one instruction; every function entry checks the running stack's floor (coro_new_sized sets how far below the region's top a coroutine may reach) and an overflow prints the C backend's "stack overflow (recursion too deep)". A program without coroutines is laid out, and checks, exactly as before.

• Regions and arenas. Every allocation comes from one bump pointer, so a

region block the main stack opened before a switch could roll back what a coroutine allocated after it: each switch raises the high-water mark, past which no rollback goes. While any coroutine exists, an arena block handed back by a compaction is not reused -- coarser than C, which keeps exactly what a stopped stack reaches.

• coro_scan_ints reads a stopped coroutine's buffer (or, for the running one,

its stack after spilling the saved registers) and follows the pointers in it as C does: three hops, without a limit above the stack's innermost open block's mark. (The outermost first: mere-ruby keeps a block open for its whole run, and with one bump pointer the whole heap counted as "its own" and was walked -- corpus 165 ran out of memory in its collector's scan.)

scripts/coro_check.sh runs its fixtures on memu at both widths (when MEMU is set; RV's failure message has no fail: prefix, and the output is compared, since memu exits 0 whatever the guest's exit said), with six RV poisons that edit the prelude (mere --rv-prelude prints it; MERE_RV_PRELUDE_FILE substitutes one). Two fixtures are new, for things the existing ones did not exercise: region_cross (the main stack's region closed after a coroutine allocated in it -- red without the switch's high-water mark) and compact_reuse (a map compacted and its blocks taken by others while a coroutine holds a value from it -- red when blocks are reused). Both run on C and the interpreter too.

The stack growing into the heap is caught too (every RV program, one instruction per call). An allocation checks gp against sp, but a call made after the heap had come close was not checked: its frame landed on heap data. Moving the heap up by the coroutine runtime's words made test/parity/region_growth.mere at 32 MB on RV64 trap in the float helpers instead of reporting the exhaustion (memu's trace stopped at a prologue with sp below gp). Each prologue now checks sp against gp (a program with coroutines checks its stack's floor instead; a --bare program, whose trap handler may run with another process's gp, does not); mere-ruby's corpus 165 run ten times takes 0.6% more instructions. And rv_exec_check no longer counts an RV run that printed NOTHING as agreeing: it compares once more with C's last line dropped (for a final value only a compiled-in main prints), and an empty run matched any one-line program -- which is how region_growth's trap passed for "now agrees" there.

v0.1.622 — 2026-10-06

_file_delete : str -> bool removes a file, on all five backends. Mere had no way to: a program ran rm -f, and a RISC-V binary on memu has no shell to run it with._

mere-ruby's File.delete is rm -f behind run. On RISC-V there is no process to start, so the eight corpus programs that end by cleaning up their temporary files stopped there, after everything else they printed had come to agree (mere-ruby 528bdd6 had just moved File.realpath and friends off the shell).

file_delete p is unlink: true when this call removed the file, false for a path that is not there, for a directory (unlink refuses one on every host; this is not rmdir), and for a refusal. It answers yes or no rather than an errno, because the LLVM backend has no portable way to read errno (__error on Darwin, __errno_location on glibc, and a weak reference to the other one does not link); a caller that needs the reason asks file_exists or the stat devices after a false.

• interpreter: Unix.unlink; C and LLVM: unlink(2); Wasm: the host's

file_delete import (scripts/run_wasm.js: fs.unlinkSync), as file_exists goes through the host.

• RISC-V: __rv_unlink is unlinkat(AT_FDCWD, path, 0), syscall 35, the Linux

number, like the openat / faccessat the hosted target already uses, and the prelude's file_delete is __rv_unlink p == 0. memu answers it (memu needs this Mere or later to build, since it answers with file_delete).

test/parity/file_delete.mere writes a file, removes it, removes it again, removes a path that was never there and tries a directory: true true false false false false true on the interpreter, C, LLVM, Wasm, RV64 and RV32. The name is random so that parity and rv_exec running it at once do not share a file.

v0.1.621 — 2026-10-06

_On LLVM and Wasm a long list carried out of a region block no longer overflows the stack (Q-201): the copy walks the list's spine as a loop, as C's has since v0.1.605._

Leaving a region block deep-copies the value into the enclosing region. For a recursive variant the copier called itself once per node -- @__mcopy_<tag> on LLVM, $__mcopy_<tag> on Wasm -- so a list's length was the copy's recursion depth. Measured: 10,000 and 30,000 elements copied, 100,000 overflowed on both backends (Q-201 had put the limit at ten million, measured only on LLVM; Wasm had not been measured). C has walked the spine since v0.1.605, for the same reason.

Both now do what C does: a constructor whose payload is a tuple ENDING in the type itself (a list's Cons, a tree's last child) copies its other fields, leaves the last one open, and goes round again with the old last field; each new node is stored into the slot the previous one left. Every other constructor is copied as before and ends the walk. LLVM keeps the walk's position in two allocas, Wasm in locals.

scripts/deep_list_check.sh gains test/deep_list/region_out_long_list.mere: 300,000-element int, str and tuple lists and a 100,000-node tree carried out of region blocks, on C, LLVM and Wasm (its expected output is in the script: the interpreter's own recursion depth stops short of these lengths). Its --poison turns each backend's loop back into a call to itself, and each then overflows. v0.1.620 overflowed on LLVM and on Wasm with the same program.

v0.1.620 — 2026-10-06

_On RISC-V a comparison with a string literal is inline, and char_at / chr allocate nothing. mere-ruby's start-up on RV64 takes 10.6% fewer instructions. The new test also found C and LLVM comparing strings with strcmp in four places, which stops at a NUL inside the value._

RISC-V. Counted over mere-ruby's start-up on RV64 (390M instructions, about 4 s on memu, almost all of it lexing and parsing the ~8000 lines of ruby it keeps as its core prelude), 4.6M of the 5.2M string comparisons were against a literal -- let c = char_at s i in ... str_eq c "x" -- at about 18 instructions each through __str_eq. str_eq x "lit", x == "lit" / != and a "lit" pattern now compare in place: the length against the literal's (a string of another length costs one load and one branch), then, for a literal that fits a word, the first data word masked to that length against the literal's bytes. The read is in bounds because every string is its length word and its bytes rounded up to whole words, and it happens only once the lengths agree. A longer literal checks the length inline and calls __str_eq only when it matches.

char_at and chr allocated two words for every character. They now return an entry of a table of the 256 one-byte strings, kept in data like a literal (a string is never written through, so nothing can tell an entry from a fresh copy).

Measured: start-up 390M → 349M instructions; mere-ruby's corpus 165 run ten times 858M → 806M, output unchanged; the binary 1.7% larger.

C and LLVM: a NUL inside a string. test/parity/str_literal_compare.mere compares strings of lengths 0 to 9 (both sides of a word at both widths) and strings with NUL, high and multi-byte characters. On C and LLVM the match arm "a" took "a\u0000c" and "" took "\u0000": a string pattern was compared with strcmp, which stops at the first NUL. == had been by length since v0.1.264; the same strcmp remained in

• C: a string pattern, a str field in structural equality (eq_*), a str in a

structural ordering, a Map's str keys (so "a" and "a\u0000b" were one key);

• LLVM: the same four.

All now compare by length (__lang_str_cmp in C, @__lang_str_eq / @__lang_str_compare in LLVM). The test has rows for each.

`lsp_smoke` no longer races. v0.1.619's CI went red on it: two publishes where three were expected. Since v0.1.576 the server handles an unbroken run of didChanges for one document as its last one, and the gate pipes every message at once, so whether the second change had already arrived when the first was handled depended on how fast the server started. Starting it a second late reproduces the failure every time. A request now sits between the two changes, which breaks the run whatever the timing.

v0.1.619 — 2026-10-06

_On the C backend a channel message no longer corrupts the heap's block lists. Since v0.1.549 examples/concurrent_loops.mere summed 1..100 to a garbage number about once in two thousand runs._

v0.1.549 put every live region block on one of two lists, so that a conservative scan of a suspended coroutine can ask whether an address may be read: the default region's blocks on a shared list behind a lock, every other region's on its thread's own list ("Map, Vec and region borrows are not Send, so a region belongs to its thread"). A channel message is the exception: the sender builds it in a fresh region and the RECEIVER frees that region. Its blocks went on the sender's list, and the receiver's unlink edited the receiver's list instead -- it set its own head to the sender's next block, and left the sender's head on a block it had just freed. Two ways that went wrong:

• two threads racing on the lists (concurrent_loops: wrong total about once in

2,000 runs alone, 5 in 4,000 under load; ThreadSanitizer names __lang_blk_link against __lang_blk_unlink);

• deterministically, when a thread sends a batch, waits for the receiver some other

way (a join is not a message) and then builds another message: its link writes into the freed block.

A region now says whether another thread frees it (xthread, set for channel messages), and its blocks go on the shared, locked list. Only the C backend keeps these lists. test/uaf/channel_xthread.mere is the second shape, run by region_uaf_check under AddressSanitizer (heap-use-after-free on every run before the fix; its poison puts the region back on the maker's list). That gate now sets ASAN_OPTIONS=use_sigaltstack=0: a spawned thread's alternate signal stack is the runtime's own (Q-178), and ASan on macOS tried to unmap it when the thread ended.

v0.1.618 — 2026-10-06

_RISC-V frames are sized by the bindings live at once rather than by every binding in the body, and a self tail call loops back past the prologue instead of rebuilding the frame. mere-ruby's corpus 165 on RV64 runs in another 5% fewer instructions; from v0.1.615 it is 47% fewer in all._

Slots are handed back. A function's frame had a slot for every binding its body made (count_lets summed them), and the first ten slots live in s1..s10, which the prologue saves and the epilogue restores. Now a binding's slot goes back when its scope ends: compile_expr restores the slot counter after each expression, and every match arm starts from the same base. The frame is sized by max_lets, the most bindings in scope at any one point, and the check after each body compares that with the counter's high-water mark (it used to compare count_lets with the final counter). The binary shrinks 7%; the count of saved registers hardly moves, because the functions that run most were already under ten.

A self tail call is a loop. Most of the remaining saves and restores were in self-recursive loops (go i acc = ... go (i + 1) ...): every iteration tore the frame down, jumped to the function's entry and ran the prologue again. A saturated self call in tail position now resets sp to the frame base and jumps to a label just after the prologue, where the arguments are copied into their slots; the saved registers stay saved for the whole loop. Calls to other functions in tail position still tear down and jump.

On LLVM, a tail call after a `let` is `musttail` again. The new parity test overflowed the stack there and nowhere else: the LLVM backend's let arms never passed tail position on to their body, so a loop of the commonest shape, let s = f i in go (i - 1) (acc + s), was a plain call that grew the stack once per iteration (at -O0; clang's sibling-call optimisation hid it at -O2). Now every let arm hands tail position on -- except a let whose fresh OwnedVec is freed at scope end, where a ret in the body would skip the free.

Not done: putting a leaf function's bindings in caller-saved registers, the other half of the plan. Counted, leaf functions pay 18% of the saves that are left, about 1% of all instructions.

Measured on that corpus: 903M → 858M instructions (slot reuse 903M → 888M, the loop 888M → 858M), binary 11.98 MB → 11.08 MB. test/parity/frame_reuse.mere reuses slots across siblings and arms and loops with eight register arguments from inside a match arm whose tuple pattern parks its pointer on the stack.

v0.1.617 — 2026-10-06

_The RISC-V backend rewrites a push/pop pair around straight-line code into two register moves, then propagates copies and drops dead moves. mere-ruby's corpus 165 on RV64 runs in another 9.5% fewer instructions, from an 8% smaller binary._

The emitter is a stack machine: an operand that must survive the evaluation of the next is pushed (addi sp, sp, -w; sd r, 0(sp)) and popped (ld r', 0(sp); addi sp, sp, w). Counted over mere-ruby those four instructions were 24% of everything run, and mv another 15%. Two passes now run over the item list before layout, so the binary, the listing and the debug map all describe the rewritten code (rv_listing_check holds them to that):

• push/pop → mv: when the code between a push and its pop has no label,

jump, branch, call or ecall, and names neither sp nor a spare temporary (t6, t5, t4), the pair becomes mv t, r / mv r', t. Nothing in between can have read the slot, and nothing can have run elsewhere and come back. Repeated until nothing changes, so nested pairs each get their own spare.

• copy propagation: inside a straight-line run, an instruction that reads

a register holding a copy made by mv reads the original instead (while neither has been written since), and a mv whose destination is written again before anything reads it is dropped. Only argument, temporary and saved registers take part, never sp, fp, gp, ra or zero, and every register's value is assumed live at the end of the run. The formats it reads are R, I, loads, S and U; any other opcode ends the run.

Measured on that corpus: 998M → 903M instructions, binary 12.99 MB → 11.98 MB. Pushes and pops that remain sit around calls, branches or nested evaluations that span them.

v0.1.616 — 2026-10-06

_On RISC-V a Map lookup is a runtime routine instead of prelude code: about 400 instructions became 91 for a str key and 42 for an int key. mere-ruby's corpus 165 on RV64 runs in 39% fewer instructions._

The RV prelude's Map is written in Mere, and every lookup went through rvmap_get → _mslot → _mprobe (one six-argument call per probe step, a tuple destructured and a bounds-checked vec_get per field), with the str hash and __str_eq called on the way. Counting every instruction of mere-ruby on RV64 (corpus 165, ten iterations) put the Map at more than half of 1.63 billion instructions, at about 400 instructions per lookup although a lookup takes 1.5 to 1.8 probe steps on average.

The lookup is now emitted as machine code:

• __rv_mslot_w and __rv_mslot_s are leaf routines that hash the key, probe

linearly and return the slot (or -(slot+1) for the first tombstone or empty slot), the same contract as the prelude's _mslot_i / _mslot. The word routine mixes the key as _mhash_i does; the str routine compares length first and then a word at a time, with the last word masked to the length.

• map_get, map_has and map_delete in user code call __rv_mget_*,

__rv_mhas_* and __rv_mdel_*; a missing key in map_get fails with the message the other backends give (map_get: key not found in Map (use map_has to check first)), and the prelude's own rvmap_get now says the same.

• map_set finds the slot with the routine and either updates in place

(__rv_mupd, which stores through __vec_set_rt so a value in an older container is copied into its arena as before) or inserts through the prelude. Insertion, growth, reindexing, compaction and iteration stay in the prelude; they run far less often.

__rv_str_hash hashes a word at a time (an FNV-style multiply per word, with the partial last word masked) instead of a byte at a time, and the str lookup shares its body, so the prelude's inserts and the runtime's lookups agree. Iteration order is unaffected (a Map iterates its entries in insertion order).

Measured on that corpus: 1,634M → 998M instructions; the Map routines and __str_eq together fall from 61% of the count to 36%.

v0.1.615 — 2026-10-05

_On the C backend a builtin's arguments run left to right under gcc as well: vec_set v (f 0) (f 1) ran f 1 first there. v0.1.614's CI went red on it._

C leaves the order of a call's arguments unspecified, and gcc evaluates them right to left. The backend had already decided this for user calls (every argument is bound to a __da temporary) and, in v0.1.450, for operators; a builtin or extern application was still written straight into a C call. So vec_set v (f 0) (f 1), map_set m (g "k") (g "v") and substring s (f 1) (f 4) ran their arguments backwards when the emitted C was built with gcc, and in order with clang -- which is what parity.sh builds with, so the parity suite could not see it. rv_exec_check builds its C reference with cc, gcc on the CI runner, and v0.1.614's new container_arenas (a random walk with two draws from one generator in one vec_set) printed another checksum there than on RISC-V.

Now an application whose head is a builtin or an extern, with two or more arguments that can have effects, binds those arguments to lets in order and applies the builtin to the variables (a closure literal counts as effect-free, so a builtin arm that inlines one still sees it). test/parity/builtin_arg_order.mere prints each argument as it runs; v0.1.614's C built with gcc printed f1 f0 gv gk f4 f1 ... for it, the interpreter's order is f0 f1 gk gv f1 f4 ....

v0.1.614 — 2026-10-05

_RISC-V containers keep their contents the way C's do: in arenas a store copies into, that a compaction frees and a recycle winds back. mere-ruby's corpus 165 and 285, which ran out of 256 MB on RV64, finish in 165 MB and 139 MB._

What was missing. v0.1.613 gave region blocks their rollback, and mere-ruby still did not fit: it stores into a long-lived table on almost every statement, each store raised the high-water mark, and its per-statement blocks gave back almost nothing. And vec_compact did nothing on this backend, map_compact only packed, map_recycle only cleared, so its collector freed no bytes. On C the same program is held at 90 MB by exactly those two things: a store copies its value into the container's own region, so a block gives back all of its garbage, and a compaction moves a container into a fresh region and frees the old one (measured: with the compactions turned off in the generated C, corpus 165 went from 90 to 129 MB; 285 was held by the blocks alone).

Arenas. An arena is a chain of power-of-two blocks, 1 KB up, carved from the bump heap a megabyte at a time (a carve inside a region block raises the high-water mark, so carves have to be rare) and given back to size-class free lists; a larger free block is split, nothing is merged. A Vec's cell has a fourth word, its arena. A container whose type says __heap is made in the shared default arena -- cell, buffer and Map tuple included -- as C makes it in the default region; vec_compact / map_compact copy the live elements into an arena of its own and free the old one (never the shared one); map_recycle empties a Map and resets its arena to the first block; vec_bytes / map_bytes answer an owned arena's capacity, 0 otherwise. A block- or parameter-region container stays on the bump heap as before.

Copy-on-store, typed at the call site. Values on this backend are untagged words, so a copy needs the type, and the prelude's Map code is compiled once for every value type (its values are erased to int; v0.1.613's note). So the copy is made where the type is known: vec_push / vec_set of a value with anything to copy call a per-type helper, and map_set is lowered to find, copy (the value; the key too when it is new -- C's rule), then update or insert. The copier is v0.1.613's __rcopy_<tag> run with gp pointed at an exact reservation that a per-type __ssize_<tag> measured first; a copy that ever ran past its reservation stops the program with that message rather than writing over the next thing in the arena. Containers and closures inside a stored value are kept as handles and, if they lie in an open block, keep it. Once any arena exists, a store into a container on the bump heap copies too, so nothing a container holds points into an arena that a compaction may free.

The contract is C's: a value read out of a container does not survive that container's compaction or recycle. RISC-V never freed anything before, so code that broke the contract ran there by accident; the first mere-ruby run on arenas crashed on two such reads, which turned out to be use-after-frees on C as well (AddressSanitizer), and are fixed in mere-ruby.

Also. The unchecked vec_set twin that loop versioning produces had no protect at all on RISC-V; it has the same as vec_set now. And test/parity/map_compact.mere leaves rv_exec_check's known differences at both widths: map_bytes has an arena to measure.

Measured on mere-ruby 770a113 (RV64, --ram 256): 165 and 285 complete (they ran out of memory on 612 and 613); startup leaves 78 MB of heap where 613 left 69. test/parity/container_arenas.mere (compaction, recycle, stores inside blocks, a random walk over twelve containers) prints the same lines on the interpreter, C, Wasm, RV32 and RV64 (LLVM has no map_recycle), and region_reclaim_check.sh --rv-only adds test/regionreclaim/arena_churn.mere: 60,000 stores into compacted and recycled containers inside blocks, 120 MB of values, in an 8 MB machine (v0.1.613 ran out of it).

v0.1.613 — 2026-10-05

_A region block on RISC-V gives its memory back again, behind a high-water mark; on LLVM a string stored into an older Map or Vec inside a block no longer dangles; and Wasm's high-water mark no longer misses a container a callee built and stored outward._

RISC-V. A region block reclaimed nothing on this backend. It once rolled gp back to the block's start, and that was unsound -- a map_set on an outer Map allocated the Map's new parts inside the block's range, and the rollback freed them -- so the rollback was taken out. It is back, with the Wasm backend's answer to the same problem: three runtime words (depth, the innermost block's mark, a high-water mark), a protect after every vec_push, vec_set and strbuf_push (a Map is Vecs since v0.1.611, so it goes through them), and at the closing brace gp returns to max(mark, high-water mark). The result is copied out by a per-type __rcopy_<tag> (str, bytes, a float's box, tuples, records, variants, recursive ones included) twice: above the garbage first, then down to where the block now ends, unless the two overlap. A block whose result is a closure or holds a container runs without rolling back, as every block did before. A failure out of a block skips the rollback, and try_or puts the depth and the block mark back. test/regionreclaim/pertree.mere: 100 trees of depth 14 run in a 16 MB machine, which v0.1.612 ran out of; region_reclaim_check.sh --rv-only is a CI step now.

Every store protects, an int's too. A version of this that skipped int stores freed a queue mere-ruby still held: the monomorphizer erases a leftover type variable to int, and one instance of the prelude's Map insert serves every Map whose values are words or pointers, so "an int" was a pointer there. The region words are per machine, so on bare metal another task's stores raise the mark into its own heap; the mark is only ever raised and a block never rolls back past its own gp, so that makes the block keep more, never less (riscv_bare_shell's background task counts into a Vec while the shell is in its per-command region). docs/bare-metal.md says what a scheduler has to do.

Wasm. Its protect raised the high-water mark only for a container older than the innermost block. A container a callee builds inside the block and stores into an older one is reachable from outside but lies above the block's mark, so when a later push in the same block grew it, the new buffer was above the high-water mark, the rollback took it, and the next block wrote over it: the new parity test read -14468027695667681 for a sum of 12350. A container below the high-water mark is protected now too -- once stored outward, that is where it is.

LLVM had no copy-on-store. Since v0.1.443 a value made inside a block lives in the block, and map_set / vec_push / vec_set stored it as the pointer it was, so a string put into an outer Map inside region R { } was read after R was released: five lines put a string into an outer Map and a Vec, ran one more block, and printed out of memory where the other backends printed v1 wx. The helpers now copy what they store into the container's region -- the C backend's rule since v0.1.30 -- but only while a block is open, so a program without regions runs the code it ran before. A Map copies a key only when it inserts it.

test/parity/region_stores_and_rollback.mere holds all three: results of every copyable kind, stores into older Maps, Vecs and StrBufs, a callee's container stored outward and then grown, nested blocks, a failure out of a block, 40,000 blocks of 1.6 KB garbage each (64 MB unreclaimed, run by rv_exec_check in 32 MB), and an int-keyed Map of queues made inside blocks (the case the skipped int protect broke). With this version it prints the same lines on the interpreter, C, LLVM, Wasm, RV32 and RV64; with v0.1.612, LLVM and Wasm did not.

v0.1.612 — 2026-10-04

_On RV64, str_of_float and float_of_str work on 64-bit words: a float is printed with about 5 KB of heap instead of 280 KB, and 1e+-5 is refused on RISC-V as it is everywhere else._

`str_of_float` (RV64). The limb library spelled a double by building its exact decimal expansion as a digit array and then trying %.{p}g for p = 12..17, parsing each attempt back: about 280 KB of heap and 7 ms on the emulator per call, never given back -- a script printing floats ran into the 256 MB. Now: Dragon4 (Burger & Dybvig's free-format algorithm) on bignums of 30-bit limbs gives the shortest digit string that reads back, the one nearest the value; when it has 12 digits or more that is exactly %.{p}g's answer, and when it has fewer, a fixed-precision pass gives the value's correctly rounded 12 digits (the same thing for a normal double, and not for a subnormal of few bits: the smallest prints 4.94065645841e-324, not 5e-324 -- rv_float_conv.mere caught the first version saying the latter). 1,000 calls: 8 MB and 1.4 s (they did not fit in 256 MB).

`float_of_str` (RV64). The lexical rules are the limb parser's, and anything that is not a plain decimal -- hex, inf, nan, not a number -- is handed to it, so its answers and messages are unchanged. A decimal D 10^k is converted exactly: for k >= 0 the top 57 bits of the product and a sticky bit, for k < 0 57-58 quotient bits of D 2^j / 5^-k by long division with the remainder as sticky, rounded once by the word arithmetic's pack (v0.1.608). Past 800 significant digits the rest becomes one sticky digit, which cannot move a rounding. 1,000 calls: 64 MB -> 32 MB, 1.9 s -> 1.3 s.

`1e+-5` was a float on RISC-V (both widths): the limb parser took any number of signs before the exponent's digits. strtod stops at the e, so it is not a number -- on RV now too, and 0x1p+-3 likewise.

Held to printf / strtod: test/float/rv_dec64.mere (random doubles by class, subnormals of a few bits included, each printed, read back, and read back from a longer spelling) and the existing rv_float_conv.mere now also run at 64 bits in scripts/rv_float_check.sh (with MEMU); 40,000 such lines over four seeds were identical to the C backend when this was made.

v0.1.611 — 2026-10-04

_On RISC-V a Map is a hash table: mere-ruby's startup there takes half the instructions, and a corpus file that ran past two minutes finishes in eleven seconds._

The RV Map was an assoc list. map_set prepended -- even over a key already there, so the list grew with every write -- map_get walked it, and map_iter walked a list of the keys it had seen once per element, the square of the length. Profiled on the RV64 emulator (through the debug map v0.1.610 made correct), that was 64% of mere-ruby's startup and 85-98% of the corpus files that timed out (_mseen, _mfind, __str_eq). C, LLVM and Wasm already had an O(1) Map.

Now the entries are kept in insertion order -- keys, values and a live flag, three Vecs -- under an open-addressing index (a power-of-two Vec: 0 empty, -1 a tombstone, n entry n-1; linear probing; grown at 3/4 full, tombstones counted). The meaning is unchanged and is every backend's: map_iter visits each live key once, in the order it was first set, with its latest value; setting an existing key keeps its place; a key deleted and set again goes to the end. Growing the index never moves an entry; map_compact packs the live entries and repoints the index without hashing again; map_clear / map_recycle empty it. A str key is hashed by a new runtime routine, __rv_str_hash (FNV-1a over the bytes, 31 bits), an int or bool key by mixing its bits; map_set now goes to the _i family by the key type too, as map_get already did.

Measured, mere-ruby on RV64: startup 939 -> 469 million instructions; corpus/67 from past 120 s (24.7 billion instructions) to 11.5 s, matching ruby. test/parity/map_random_ops.mere is a deterministic random walk of set / delete / get / has / len / iter / compact / clear over a small key space (str and int keys) whose output every backend must reproduce; RV32 and RV64 do.

v0.1.610 — 2026-10-04

_mere -rvs / -rv64s (the listing) and -rvg / -rv64g (the debug map) describe the binary -rv emits, word for word -- they were made from a different program, and a profile read through the map blamed the wrong functions._

The listing and the map skipped settling the regions. Q-127 settles every undecided container region (bind_region_params, default_container_regions) before code is generated; emit_program did, and emit_listing / emit_debug_map did not, so they generated code for a slightly different program. On 15 of the parity programs the listing's words were not the binary's; on mere-ruby every address in the map was off -- a sampling profile of its startup on the RV64 emulator, read through it, said 26% was do_class_alias and 7% lgamma's helper, where the truth is the Map (the next version). settle_regions is now one function the three paths share.

A wide listing encoded its jumps as J-type anyway. Past 512 KB of code a jump is emitted as auipc + jalr, and the listing printed it so -- after encoding it as a J-type first, which refuses anything over 1 MB: mere-ruby's listing stopped with "a jump of 2441396 bytes does not fit". It is encoded only when it is one now.

scripts/rv_listing_check.sh (in CI): for every parity program at both widths, each encoded word the listing shows is the binary's word at that address, and each function symbol of the debug map is a listing label at that address; plus a generated 1.25 MB program whose 12,030 jumps are all wide (v0.1.609 refuses its listing). 273 listings, 1.3 million words.

v0.1.609 — 2026-10-04

_RISC-V has a libm: an extern fn cbrt: float -> float (and twenty more of libm's names) is answered by the prelude instead of refused, and those, sin, cos, tan, atan2, exp, log and f_pow are correctly rounded there -- within ~0.52 ulp of the true value, sin 1e22 included._

The libm (lib/rv_libm.ml, appended to the RISC-V prelude). mere-ruby declares twenty-one libm functions as extern fn for its Math module, and on RV32IM / RV64IM every one was a named refusal: Math.cbrt, Math.hypot, Math.gamma, Float#% (fmod) and Math.ldexp stopped the script. An extern whose name is one of atan asin acos sinh cosh tanh asinh acosh atanh cbrt log2 log10 log1p expm1 erf erfc tgamma lgamma (float -> float), hypot fmod (float -> float -> float) or ldexp (float -> int -> float) AND whose declared type is libm's is now bound to __libm_<name> in the prelude (codegen_riscv's libm_bound); on a host the same declaration still links libm. Another type under one of these names is refused as before.

Correctly rounded, not "libm's bits". Each function is computed in double-double -- pairs of doubles carrying ~106 bits, built from the prelude's two_sum / two_prod with new __dd_add / __dd_mul / __dd_div / __dd_sqrt / __dd_exp -- and rounded once. Every function was prototyped operation for operation in Python (whose floats are the same IEEE doubles) and measured against a 50-digit reference over thousands of points: all are within ~0.52 ulp of the true value, fmod and ldexp exact. The Mere transcription was then held to the prototype bit for bit on 7,500 random calls on RV64. macOS's libm, measured the same way, is NOT correctly rounded for most of these -- cbrt, the inverse and hyperbolic functions, hypot, tan, erf, erfc, tgamma, lgamma are a ulp away on 3% to 49% of points (lgamma near its zeros by hundreds) -- so the gate, test/float/rv_libm_ext.mere, holds 502 results (mere-ruby's corpus/168 inputs, the IEEE specials and each function's edges, and random points) to the correctly rounded values in rv_libm_ext.expected, not to the host's. scripts/rv_float_check.sh runs it on RV64 and RV32 (256 MB there) with MEMU. The same 502, from the C backend linked against each host's libm: macOS disagrees on 39; glibc 2.39 (the CI image, arm64 and amd64) on 4, all lgamma, which glibc does not round correctly either -- so a RISC-V build of a program prints what it prints on Linux. erf is a positive-term series below 2 and erfc a 120-level continued fraction above it; tgamma and lgamma are Stirling's series past 12 with the shift in pairs, a zeta series within 0.1 of 1 and 2, and reflection below 0.

The builtins on the same pieces. sin, cos, tan and atan2 moved to lib/rv_libm.ml with double-double kernels; exp, log and f_pow keep their code with a more precise core under it (__fp_exp_core carries r^3/6 in a pair, __fp_log2p the series' first three terms and s's tail scaled by 2/(1 - s^2)). Against libm on the v0.1.606 sweeps: f_pow 47 -> 7 points apart, log 4 -> 0, exp 2 -> 3 -- and on every one of the remaining ten the prelude is the correctly rounded one. Three faults found on the way:

• the sin and cos series stopped at 1/17! and 1/14!, and r^16/16! at pi/4 is

1.6e-15: that was most of their documented "<= 10 ulp";

• __fp_pio2_2, a piece of the three-piece pi/2, was written with fifteen

digits, not as fdlibm's double, so pi/2 was 6.5e-26 off and tan of the double nearest pi/2 was wrong in the ninth digit;

• past 2^20 that reduction is not exact, and nothing replaced it: sin 1e22

answered 7.9e91. Arguments that large now go through Payne-Hanek (2/pi to 1,248 bits, as 24-bit chunks in an if-tree, so nothing is built at startup) and are as accurate as small ones.

v0.1.608 — 2026-10-04

_On RV64, a double is one 64-bit word while it is computed: float arithmetic allocates nothing but its result, 20,000 operations fit in 4 MB instead of 64, and run four times as fast. RV32 is unchanged._

Float arithmetic on RV64 without limbs. Both RISC-V widths computed a float operation in contrib/softfloat's 15-bit limbs -- the width that keeps a limb product inside RV32's signed 32-bit int -- building a record per operand per step: about 2 KB of heap per +, and a region gives nothing back on these targets. mere-ruby's ** cost ~600 KB there. On RV64 the int is 64 bits, so the IEEE pattern is one word and the 53-bit significand fits with room to spare: + - * /, sqrt, the comparisons, f_abs, f_neg, float_of_int and int_of_float are now the same algorithm (pack with guard/round/sticky, long division, digit-by-digit root, every NaN rule) on words, as top-level functions of ints that build no tuple or closure. Measured on the emulator: 20,000 float operations fit in 4 MB (64 MB before) in 0.56 s (2.22 s); 400 f_pow in 8 MB (128 MB) in 1.53 s (3.64 s). The decimal conversions (str_of_float, float_of_str) still go through the limbs.

The two are held to each other and to the hardware: rv_float_ops.mere's 3440 operations give the machine's bits on RV64 as on RV32; a new random-operand sweep, test/float/rv_float_fuzz.mere (zeros, infinities, quiet and signalling NaNs, subnormals, both exponent edges, cancelling neighbours), gives the machine's bits on all 16,000 results except where both sides are NaN; and 320,000 results of the same sweep under eight seeds were identical to the limb library's on RV64, NaN payloads and out-of-range int_of_float included. scripts/rv_float_check.sh runs both RV64 checks when MEMU is set.

`if __rv_xlen () == N` is decided at compile time (codegen_riscv's xlen_test): the branch for the other width is neither compiled nor counted as reachable. That is what lets the one prelude hold both arithmetics -- an RV32 image carries no 64-bit code (its size is unchanged), and an RV64 image no limb code (a float program's image went from 84,285 to 77,441 bytes).

v0.1.607 — 2026-10-04

_On RISC-V, print_bytes writes its bytes (a NUL included) instead of stopping, and a refusal on RV64 names RV64I rather than RV32I._

`print_bytes` on RV32IM / RV64IM was a stub ("needs a host") although a bytes value has been a str block there since v0.1.426 and the write goes by the length word: it is now that write, so a NUL in the middle goes out like any other byte, as on every other backend. docs/host-matrix.md: stub -> yes.

The machine a message names. Every message of this backend was written for RV32I and began with that name, so on RV64 mere-ruby reported "RV32I: fd_pipe is an extern fn". err and emit_abort now spell it RV64I on RV64; the 32-bit spelling is unchanged, because host_matrix.sh and rv_prelude_check.sh key on it. Two texts said --bare on the hosted path too: an unimplemented host service now says "needs a host service this target does not provide (a hosted run answers a fixed set of Linux calls; --bare answers none)", and an extern fn "has no C library to link against -- the program is the whole machine image" (the part mere-ruby matches on is as it was). test/rv/print_bytes_and_names.mere runs at both widths in scripts/rv_exec_check.sh (with MEMU).

v0.1.606 — 2026-10-04

_On RISC-V, f_pow, exp and log answer what libm answers: within 1 ulp everywhere, and the same bits on all but a few points in a thousand. 2.3 ** 3 is 12.166999999999998 there now, as everywhere else. An extern whose parameter is unit can be called with a unit-typed variable on C and LLVM._

`f_pow` / `exp` / `log` on RV32IM and RV64IM (found by mere-ruby on RV64, corpus 105 and 173). These are prelude Mere over softfloat there, and libm on every other backend. Measured against libm on 6000-call sweeps: f_pow disagreed on 3131 points by up to 20 ulp, exp on 303 by 1, log on 598 by up to 2; mere-ruby printed 2.3 ** 3 as 12.166999999999996 and 8 ** (1.0 / 3) as 1.9999999999999998. Now 47, 2 and 4 points, each 1 ulp (f_pow's worst is 0.71 ulp from the true value; on most of the 47 libm is the closer one). Three changes, all built from exact two_sum / two_prod (Dekker) pieces and rounded once at the end:

• the log's HEAD+TAIL pair carries the rounding of s = (m-1)/(m+1), which

was up to 4e-17 -- a whole ulp of log near 1, and y times that in f_pow;

• __fp_exp2 takes its argument as a pair, sums 1 + r + r^2/2 exactly, and

scales the argument's tail by all of e^r: the first version scaled it by 1 + r and was six ulps off at |y ln x| = 190, where the tail is 1e-14;

• integer exponents |y| <= 32 walk the binary powering as pairs. The plain

walk stays as the first step: it is exact where the answer is exact, and outside [2^-960, 2^960] (where a pair cannot be split) its answer stands. The cost is time and memory: a f_pow is about 2.3x the work, and on these targets every float operation allocates (about 2 KB through softfloat's limbs, and a region gives nothing back), so a f_pow now takes ~600 KB of the heap instead of ~300 KB. test/float/rv_libm_points.mere holds 66 points of the three to libm's bits -- points that 605 got wrong -- and scripts/rv_float_check.sh runs it on RV32I when MEMU is set; RV64 gives the same bits.

An extern's `unit` parameter is dropped by its type (found while wrapping mere-ruby's externs). The C prototype drops a unit parameter by its declared type (extern int getpid(void);), but the call dropped only a literal (), so fn (u: unit) -> getpid u emitted getpid(mu_u) and clang refused the program; LLVM declared @getpid() and called it with an i64, which linked by luck. Both calls now drop the argument by the parameter's declared type, and a non-literal one is still evaluated, ahead of the call. test/ctests/extern_unit_param_variable.mere (clang) and a test_basic case (the LLVM call) hold it.

v0.1.605 — 2026-10-03

_A chain of literal ++ is one literal by the time it is compiled, and a list is copied along its spine by a loop: ten million elements no longer run the copy out of C stack, and a 6703-line text written one literal per line no longer costs the square of its length at startup. On Wasm, a region block's result no longer overwrites itself on the way out._

`"a" ++ "b"` is folded (found by mere-ruby). A text written as a chain of literals -- mere-ruby's Ruby prelude, one line per literal -- was concatenated when the program ran, every link copying everything before it: the copies came to 192 MB at every startup of mere-ruby, which is most of what -e 1 used, and on RISC-V, where a region gives nothing back, more than the 256 MB a program has there. fold_str_concat (lib/pipeline.ml) runs after parsing with the other lowerings, so mere fmt, which keeps the sugar, still prints the chain as it was written. Two literals become one; x ++ "a" ++ "b" folds its tail; "a" ++ x is left as it is. mere-ruby's -e 1: 244 MB -> 46 MB (with the joined prelude built in a region). Three unit tests used two literals to look at the code ++ makes; they put a variable on one side now.

A recursive variant's copier walks its spine in a loop. __mcopy_<tag> (copy-on-store) and __mdeep_<tag> (a region loop's carry) recursed into every node, and a list is one node per element: three million elements stored into a map ran out of the default 8 MB stack ("stack overflow (recursion too deep)"), and mere-ruby's Array.new(10_000_000) out of its 512 MB one -- in CRuby's test_method that was rest(*(1..10_000_000)), and the whole file with it. A constructor whose payload is a tuple ENDING in the type itself (a list's Cons) is now walked as a loop along that field, each new node linked into the slot the previous one left; the other fields and every other constructor are copied as before. scripts/deep_list_check.sh stores a 3M-element int list and str list into maps and carries one through a region loop under an 8 MB stack, and --poison puts the recursion back and requires a failure; in CI. The LLVM copier still recurses (a ten-million-element list carried out of a region overflows there); Wasm's is not measured.

On Wasm, a region block's second copy ran into its first (shown by the fold). A Wasm region block copies its result twice -- above the block's garbage, then down to where the block began -- and when the garbage is smaller than the value, the second copy writes over the first while it reads it: a record whose first field is a string had the string's bytes written over its second field (region R { rec_t { name = "abcdefgh", n = 4 } } read n as 1751606885, the bytes of "efgh"; a longer one ran out of memory). It took a string LITERAL to show it -- a string built in the block was garbage enough to keep the copies apart -- and folding turned region_result_boxed's "na" ++ "me" into one, and the parity gate went red on Wasm. When the copies would overlap, the first is now the result and the bump is left after it. test/parity/region_result_over_its_copy.mere; it fails on v0.1.604.

v0.1.604 — 2026-10-03

_A zero divisor fails on RISC-V as everywhere else: 7 / 0 printed -1 there, and 7 % 0 printed 7. And on the -rv path a second type error is shown in the program, not in the prelude._

RISC-V's div and rem do not trap: a zero divisor answers -1 and the dividend, which is defined behaviour for the instruction set and a silent wrong answer for the program -- the interpreter, C, LLVM and Wasm all fail with "division by zero" / "modulo by zero". Each division now branches on a zero divisor to one of two shared stubs (emitted only when the program divides) that fail with those messages, catchably: try_or and try_or_msg take them like any other failure. INT_MIN / -1 needed nothing: RISC-V answers the wraparound the interpreter does.

And on the same path: with two or more type errors, every one was shown as <rv-prelude>:2:9 with a line of the prelude under it. The report re-checks the file as it was given -- without the prelude glued in front -- and its positions were then moved again as if they counted from the prelude's first line; they are the file's own now (scripts/rv_prelude_check.sh gains the case).

Found while giving this backend try_or_msg (v0.1.599). test/parity/divide_by_zero_caught.mere is the same on all four backends and, through scripts/rv_exec_check.sh, on RV32 and RV64. Every RISC-V binary that divides changes; no other backend's output does.

v0.1.603 — 2026-10-03

_dom_canvas_put_pixels: a browser program puts a whole frame on a canvas in one call (Q-122)._

contrib/dom's canvas could set a fill colour and fill a rectangle, so a renderer drew a frame one 1x1 rectangle -- one host call -- per pixel, and the note beside the bindings put a blit off until "typed-buffer FFI". That never came, and was not needed: a bytes already crosses the Wasm boundary as its length and then its bytes, and Wasm has had ByteBuf since v0.1.585 to build one in.

dom_canvas_put_pixels canvas px w h draws a w x h image at the canvas's top-left corner from px, four bytes a pixel (RGBA), row by row; the glue copies them into an ImageData (one cannot be made over a view of a threaded module's shared memory) and calls putImageData. Fewer than w h 4 bytes is refused by name -- dom_canvas_put_pixels: a 2x3 image needs 24 bytes, got 16 -- rather than drawn short.

scripts/run_dom_headless.mjs gains a canvas whose 2d context records what was drawn, and scripts/dom_canvas_check.sh (in CI) builds test/dom/canvas_put_pixels.mere and checks the frame arrives pixel for pixel and the short one is refused. m3d's browser build and mbrowse's browser output were the two programs waiting on it.

v0.1.602 — 2026-10-03

_A top-level name defined a second time is warned about: everything above the second definition -- including a let rec ... and group -- still means the first._

Since v0.1.588 top-level functions may come in any order, and a second definition of a name shadows the first for what follows it. Nothing said so. Splitting mere-ruby's big let rec groups into separate definitions showed what that costs: nine names quietly came to mean an earlier definition of the same name -- three of them a function of the same type, which no type error can catch (Q-157). The warning is the precondition for doing that split safely:

warning: `f` is defined again at the top level (first at line 1). From here on it
means this one; everything above -- including any `let rec ... and` group that
uses it -- still means the first. Rename one if that is not the intent

It is given on every path (check, the interpreter, the compilers) when both definitions are the program's own: in the same directory, so two libraries with a private helper of the same name do not warn in every program that imports both, and not inside an installed package (.mere_modules/), which its user cannot edit. A definition that keeps a let fn promise is not a second one, and a program's own version of a prelude name is not warned about. In this repository and its downstream programs it names 6 files; in mere-ruby, 7 names (all_digits, hex4, hex_val, is_ws_ch, norm_ccc, rev_app_str, str_has_nul) -- which are what to settle before its groups are split.

v0.1.601 — 2026-10-03

_channel_sender ch h: a channel that is told who sends on it stops a receive from waiting once all of them have finished -- naming the sender that failed. On all four backends._

Since v0.1.586 a failed thread no longer takes the program down, and a channel did not know its senders: a receive waiting for a message a failed thread was going to send waited for good, with nothing to wake it. Joining the thread first fixes the one-shot workers (and par_map, v0.1.590); it cannot fix a producer that lives as long as the program -- an actor, a broadcaster, an accept loop.

channel_sender ch h registers thread h as a sender of ch. Once every registered sender has finished and the channel is empty, a receive stops waiting as it does on a closed channel:

• channel_recv fails, catchably: channel_recv: sender thread 2 failed: fail:

boom -- the first registered sender that failed, with its message -- or channel_recv: every sender has finished and the channel is empty;

• channel_recv_opt and channel_recv_timeout answer None.

A channel with no sender registered behaves exactly as before, and a program that never calls channel_sender compiles to the same C as before. It is opt-in on purpose: the alternatives the investigation weighed -- closing every channel a failed thread held, counting senders, waking every receiver on any failure -- each broke a program that is correct today.

How each backend sees a sender end: the interpreter wakes the channels a thread was registered on when it ends; C and LLVM read the thread record (v0.1.586) and, with senders registered, look again every 50 ms while waiting; Wasm keeps each thread's status in the first 512 bytes of its private region of the shared memory, where any thread can read it, and a channel there takes at most 256 senders (past that, channel_sender fails by name: a worker cannot allocate the list a bigger one would need). test/parity/channel_senders.mere holds the answers -- values sent before a failure still received, the failure named, the all-finished case, and a timeout answered at once -- the same on all four.

v0.1.600 — 2026-10-03

_channel_close, channel_recv_opt and channel_recv_timeout on LLVM and Wasm, and a Wasm thread sees the program's top-level values: parity checks concurrency_channel and channel_unconstrained_elem on all four backends, which leaves 13 programs unchecked on LLVM and 6 on Wasm._

The three were interp and C only, and they are what a worker loop uses to end: mere-blog's app had no other gap on Wasm.

• LLVM. The channel gains a closed word. channel_close sets it and wakes

every waiter; a send on a closed channel and a channel_recv on a closed, drained one fail catchably with the C runtime's messages. All receives go through one routine that waits (with a deadline, for the timeout) and reports whether it took a value, returned by value so a receive in a loop allocates no stack.

• Wasm. The host's channel gains closed and a sequence word every send

and the close bump; a waiter waits on the sequence, so a close that lands between its last look and its wait still wakes it. One host call does every receive and writes the value into memory the module names.

• The option. Neither backend can build an option from inside a runtime

call, so before emission channel_recv_opt ch becomes let p = __chan_recv_pair ch in if fst p then Some (snd p) else None (Ast.rewrite_channel_ops), every new node typed from the original's, and a type nothing constrains erased to int as these backends erase it.

• A Wasm thread read every top-level value as 0. Top-level values are Wasm

globals, one set per instance, and a spawned thread is a new instance: a top-level function called from a thread read a channel at address 0 or a count of 0. A spawning program now exports them and the host copies their values into each new thread's instance. test/parity/thread_reads_toplevel.mere.

test/parity/channel_close_family.mere covers what each answers -- queued values surviving a close, the two failures, a timeout that expires and one that does not, and workers ended by a close -- the same on all four backends. Every program's LLVM IR changes (the channel runtime is in each); C, RISC-V and -t output do not.

v0.1.599 — 2026-10-03

_The RISC-V backend takes Maps keyed by int or bool, a local let rec ... and ..., a top-level function at another arity, and try_or_msg: mere-ruby builds for RV64 again (it stopped at the first of the four)._

mere-ruby's RV64 build -- the interpreter compiled for a CPU that is itself a Mere program -- had been refused since mere-ruby keyed its object table by object id. Fixing that showed the next refusal each time; there were four.

• Maps keyed by `int` or `bool`. The prelude's Map is an assoc list compared

with str_eq, which read an int key as a string's address, so such a key was refused. A Map whose key type is int or bool now goes to an rvmap_*_i family that compares with ==, chosen from the Map's own type so map_len and map_iter (no key argument) agree with map_set.

• A local mutually recursive group. Only a single local let rec was

compiled; a group allocates every member's closure block and binds it before filling any captures, so members that call each other read each other's blocks.

• A top-level function at another arity: f a b for an f of three, a bare

f passed as a value (both refused, "no currying layer"), and f a b c d for an f of three. The first two are the closure the source means -- the given arguments evaluated once, in order, straight into a closure block whose code calls f with them and the rest -- built from values rather than frame slots, so the enclosing function's frame is unchanged. The third is the saturated call with the remaining arguments applied to its result. A function of one argument goes through its adapter as before.

• `try_or_msg`. It is try_or with a handler where the default was; the

unwind leaves the failure's message in a1 and the catch path calls the handler with it. In a program that calls try_or_msg, a fail the program wrote tags its message fail: as every other backend does, so the handler reads the same text -- and the prelude's own fails, which stand in for builtins' failures (random_int, map_get), do not, as theirs are untagged everywhere. A program that does not call try_or_msg keeps the bytes it had (its uncaught message is still printed untagged on this backend).

Four parity programs cover these (map_word_keys, local_mutual_rec, partial_top_fn, try_or_msg_catch); interp, C, LLVM, Wasm, RV32 and RV64 print the same. Of the 1,022 programs swept, every one that built for RISC-V before builds to the same binary, except two whose functions come out in a different order (the same 172 functions, each the same size: the table they are emitted from grew), and 63 that were refused now build.

v0.1.598 — 2026-10-03

_file_exists, sleep_ms and random_int on LLVM, and random_int's failure names the bound on C as it does everywhere else._

The three were the first wall for a dozen downstream programs on LLVM (file_exists alone for mengd, mreg, mraft, mk and mere-ruby). They give the C runtime's answers: whether the path names something (access(F_OK), since stat would need the platform's struct layout in IR), a sleep that does nothing for a count of zero or less, and a uniform int in [0, n) from rand, seeded once from time ^ pid. A libc function the program also declares as an extern is declared once.

random_int 0 failed with "random_int: bound must be positive" on C and with "... (got 0)" on the interpreter, Wasm and RISC-V; C and LLVM say "(got 0)" now. test/parity/file_exists_random_int.mere holds what of this is deterministic; docs/host-matrix.md shows the three as yes on LLVM.

v0.1.597 — 2026-10-03

_A tuple pattern nested in a let compiles on every backend: parity checks every program on C (206 of 206), and leaves 15 unchecked on LLVM and 8 on Wasm._

let ((a, b), (c, d)) = t in body ran in the interpreter and was refused by C, LLVM and Wasm ("nested pattern in let-tuple not supported ... use match"). The backends now see it as one flat let per level -- let (__lt0, __lt1) = t in let (a, b) = __lt0 in let (c, d) = __lt1 in body -- written by Ast.flatten_let_tuples after type checking, each new variable typed from the value's tuple type. A subtree with nothing to rewrite stays the same node, so the tables keyed on nodes still find it. It applies inside functions as well as at the top level, to any depth, with _ and functions as components (test/parity/nested_let_tuple.mere).

The C, Wasm, RISC-V and -t output of every other program in the repository and downstream is unchanged (4,086 comparisons).

v0.1.596 — 2026-10-03

_The LLVM backend erases a leftover type variable like the other backends, lifts a let rec written in the program's body, and stops mistaking externs for captures and t0 for a register: parity leaves 16 programs unchecked on LLVM (was 19), mpng builds with it and passes its 33 checks, and 42 programs that clang or the emitter refused now build._

• A type variable that survives to emission -- the result of a function

that never returns, a helper whose error type nothing constrains -- was refused ("unsupported LLVM codegen type element: 'a") where C and Wasm erase it to int. ty_tag erases it here too (llvm_ty_of already lowered it to i64), and the instantiation pass names the erased instance a residual call site asks for, as it does for C and Wasm (recover_promoted: without the concrete instances C and Wasm also get, which this backend finds through its own table). result_residual and free_result_thrown_away are checked on LLVM now. A tuple holding such a variable is declared under its erased name when nothing in it is a type constructor (let (f, g) = (fn x -> x, ...)).

• `let rec` in the program's body -- not inside a function -- was refused

("let rec inside an expression"); it is lifted under the host $main as the C backend has done. It was the first wall for mpng and medit2. region_outer_push_realloc is checked on LLVM, and test/parity/main_let_rec.mere covers a capture, mutual recursion and a let rec inside a lifted one.

• Externs are not captures. An inner function that called an extern took

it for a free variable and passed a local that does not exist ("use of undefined value '%tcp_write'"); the C backend fixed the same thing in v0.1.61.

• A parameter named `t0` collided with the temporaries fresh_reg names

%t0, %t1, ... ("multiple definition of local value named 't0'", mpng's chunk out t0 t1 t2 t3). Such names get a suffix with a dot, which no Mere identifier has.

Of 1,022 programs (test/, examples/, the downstream programs), 42 whose LLVM IR the emitter or clang refused now build and none that built stops; the C, Wasm, RISC-V and -t output of all of them is unchanged.

v0.1.595 — 2026-10-03

_floor, ceil and round on Wasm, and a negative zero printed as -0.0 there: contrib/raster's path library builds for Wasm, and parity leaves 9 programs unchecked on Wasm (was 10)._

The Wasm backend refused all three. floor and ceil are f64.floor and f64.ceil; they were held back because putting them in the eta-expansion list sent it into an infinite expansion, so a call is emitted directly and the bare name as a value is still refused. round is not f64.nearest, which rounds half to even where C and the interpreter round half away from zero: it is the truncation, moved one away from zero when the part cut off is at least a half -- computed from the truncation rather than as floor(|x| + 0.5), which rounds 0.49999999999999994 up because the sum is 1.0 in a double.

The Wasm host printed -0.0 as 0.0 ((-0).toFixed(0) is "0"); it prints -0.0 like the other three.

test/parity/float_round.mere covers halves, negatives, the 0.49999999999999994 case, negative zero and a value past 2^52. contrib_ctest unpins raster/path; docs/host-matrix.md shows the three as yes on Wasm.

v0.1.594 — 2026-10-03

_Five more places where building a program took time quadratic in its size are linear: mere-ruby's -c is 3.8 s (was 7.3) and its check 1.4 s (was 1.8), and every output is the same bytes._

Each was found by a program of one repeated shape, 2,000 and 16,000 times over; scripts/infer_scaling.sh now measures all five, and v0.1.593 fails each of them (42-85x for 8x the program).

• The top-level environment (check and every emitter). A program is a chain

of lets, and the environment at the thousandth one is a list a thousand long: every name bound early was found by walking past everything bound since. 16,000 top-level let g = map_new () took 17.9 s to check and 24 s to emit C. The type checker and the move checker now keep that chain as a persistent map, extended by each top-level let for its body (Env_index.extend) and moved along by the declaration loop (Env_index.track); a lookup walks only the bindings in front of it. check 0.38 s.

• The C emitter's variables in scope were the same list again; a map now.

-c 0.59 s.

• Instantiating polymorphic helpers. Asking where a helper is used visited

every instance of every multi-instantiated function; the instances' uses are filed by name, read back in the order the old walk produced them, which is the order that decides which instance the C lists first. 8,000 helpers used at two types: 43 s → 1.2 s.

• Lifting inner functions. Each lift turned every top-level name into a set

again (94 s for 16,000 functions with an inner let rec); the set is kept. 1.2 s.

• A long operator chain, as generated code writes one: its left spine was

collected by appending each link to the ones below it. 16,000 links: 1.6 → 0.08 s.

The C, LLVM, Wasm, RISC-V and -t output of 1,022 programs (test/, examples/, the downstream programs) and mere-ruby's C are byte-identical to v0.1.593's.

v0.1.593 — 2026-10-03

_Three walks in the C emitter that were quadratic in the program are linear: mere-ruby's emit is 6.6 s (was 7.8), and the C it emits is the same bytes._

• resolve_vec_let_types walked the rest of the program once per let whose

container type was still open. It is now one walk that records each binding's uses, honouring shadowing, and then unifies them in binding order -- the order the old per-binding walks ran in.

• The set of free variables a closure skeleton uses, and the bound names inside

free_vars, were lists searched with List.mem; they are a hash table and a string set.

The C for 1,022 programs (test/, examples/, the downstream programs) and mere-ruby's C are byte-identical to v0.1.592's.

v0.1.592 — 2026-10-03

_The C a standalone program compiles to has internal linkage, and a curried function's closure stages call its uncurried twin: mere-ruby's C is 40 MB (was 93), clang -O2 builds it in 54 s (was 185) in 1.4 GB (was 6.9)._

A top-level function f = fn a -> fn b -> fn c -> body is emitted twice: as f__direct(a, b, c), which every saturated call uses, and as the closure chain that a partial application or a first-class use goes through. The chain copied body into every stage and every stage's two-argument entry -- a number of copies that grows like the Fibonacci numbers with the arity (6 for three parameters, 56 for ten) -- and in a standalone program all of it had external linkage, so clang kept and optimised every copy whether anything reached it or not. mere-ruby's C was 92.9 MB, 59 MB of it closure stages; clang -O2 took 185 s and 6.9 GB and produced a 24 MB binary. Developers waited on clang for over 90% of a build.

• Internal linkage. The program's own definitions -- top-level functions,

their stages, their _as_value constants -- are static in a standalone program as they already were in a library: nothing outside the one translation unit links to them. Except under -g, where a debugger breaks on a function by its name and an unreferenced static one is dropped even at -O0 (scripts/debug_info.sh caught it).

• The chain calls the twin. The curried form's innermost body is now a

saturated call of the function itself, which the emitter sends to the twin, so the body exists once. Only where the twin takes no region arguments and no parameter is named like the function.

mere-ruby: C 92.9 → 40.2 MB, clang -O2 185 → 54 s, 6.9 → 1.4 GB, binary 24 → 5.4 MB, its emit 12 → 7.8 s; its corpus matches Ruby on 276 of 276. parity, examples_parity, debug_info, lib_check and downstream_cc_check (23 programs) pass.

v0.1.591 — 2026-10-03

_A function whose result is a free type, used at two types, is instantiated at both: the C build of such a program no longer fails in clang._

raise_exc = fn (msg: str) -> fail msg has type str -> 'a. Used for its value at v by one caller, it was resolved at v; called from a function whose own result is thrown away (so its type variable is erased to int), that call named the same v instance, and clang refused the C: "returning 'v' from a function with result type 'long long'". Seven lines reproduce it, and mere-ruby meets it as soon as its giant let rec groups are split. The recovery pass that already handles residual uses of multi-instantiated functions now also handles a function resolved at one type whose residual use agrees on every parameter and differs only in the result: it becomes multi-instantiated, and each call names the instance for its own type. A residual variable in a PARAMETER position is left alone -- erased to int it would name an instance whose closure parameter does not match (contrib raster's comparators showed it).

The same pass now reads an index of the emitted bodies -- each name's uses and its live references, filed per body in the order the walk visited them -- instead of walking all of them once per function per round (the new check would have made mere-ruby's -c 75 s, and a 16,000-member group 12 s). Every .mere in the repository and downstream emits byte-identical output on all five emitters (5,110 comparisons); test/parity/fail/result_free_two_types.mere holds the new case (it fails on purpose: 3, then fail: 500).

scripts/procsig_check.sh (v0.1.589) failed on CI only: a CI runner starts its steps with SIGPIPE ignored, and a shell cannot undo a disposition it was started with, so the scenes that need nothing inherited were the inherited one. They put the default back with perl first.

v0.1.590 — 2026-10-03

_What v0.1.586 left behind: par_map joins before it receives (a failing element hung every backend), a thread's failure is printed when it happens (a daemon never reached the exit that printed it), and C's closed channels fail catchably._

v0.1.586 stopped a spawned thread's failure from ending the program. Three consequences of that surfaced afterwards:

• `par_map` hung. It is lowered to a thread and a channel per element and

received without joining, so a failure in its function left the receive waiting for a message nobody would send -- on all four backends, and in a real program (mk). Every element's thread is now joined before its result is taken: the failure is raised in the caller, where try_or takes it, and par_map threads are no longer reported "never joined".

• A daemon's failures were silent. The failure line of a thread nobody

joined or detached went out at exit, and a server whose handlers' handles are dropped never exits. The line now goes out when the thread fails, whoever holds the handle -- Rust's panic message, the same four-backend text: mere: thread 1 failed: fail: boom. join still raises the failure again.

• C aborted on a closed channel. channel_recv on a closed, empty channel

and channel_send on a closed one were abort() (exit 134, past every try_or) where the interpreter fails catchably. They fail by name now.

The fan-in examples join their workers before reading what they sent (parallel_compute, parallel_channel, concurrent_loops, pubsub), as the docs now advise. scripts/thread_fail_check.sh expects the new line and gains par_map_fail (four backends) with a poison that drops the join.

v0.1.589 — 2026-10-02

_A recycled map keeps its block's real capacity; no out-of-memory fail while the region lock is held; the pin that keeps an arena for a suspended coroutine follows the pointers it finds and remembers who it is for; a signal's disposition, a refused write to stdout and socketpair(2), which no extern can reach._

`map_recycle` ran off the end of the block it kept (found by mere-ruby). A recycle keeps the OLDEST block of a map's private arena and calls it the 4 KB seed. But a value bigger than a quarter of the seed gets a dedicated block (v0.1.307), chained in behind the bump block -- so while the seed is still the bump block, the oldest block IS the dedicated one, and r->cap = 4096 claimed 4 KB on its 2 KB: the next allocations ran into the heap beside it. In mere-ruby's frame pool that was a 2.8 KB exception message, a corrupted length, and a deep copy that asked malloc for the impossible. The recycle now keeps the block's own capacity (b->pad). test/uaf/recycle_dedicated.mere, built with ASan by scripts/region_uaf_check.sh (a case marked a), and its poison -- the old r->cap = 4096 -- goes red. (A map was the only container with a recycle; the region cache's release already kept best->pad.)

...and that malloc failure left the program stopped, silently. An allocation in the default region takes its lock, and a malloc that failed inside __lang_region_alloc -- a dedicated block, a new bump block, an in-place grow -- called __lang_fail_impl with the lock still held. A try_or above caught the fail; the next allocation waited on the lock its own thread held, at 0% CPU, forever. Each of the three now unlocks before it fails (add_block has a _try form for the one under the lock). Not under a gate: it needs a malloc that fails, which a test cannot ask for portably.

Two holes in the pin (v0.1.547), found by running a collection on a coroutine of its own. mere-ruby now collects in the middle of a method by switching to a coroutine and compacting there, so the method's stack is a suspended one -- the case the pin exists for -- and the first corpus run under a collection at every safepoint was a use-after-free in both of these ways.

• The pin read only the stack's own words. A stack holds a pointer to a node

-- a list cell, a tuple, a closure's env -- and the node holds the pointer into the arena being compacted. That arena was freed under the node. The pin now gathers what the stack REACHES, by the walk coro_scan_ints already makes: as far as the pointers go inside the coroutine's own regions, three hops into anyone else's (__lang_pin_reach). Once per stop, as before.

• A retired arena was freed under the coroutine that pinned it. Every later

retirement tries the retired arenas again, and asked only the SUSPENDED stacks -- so once the coroutine that pinned an arena was running again, and still holding the pointers that had pinned it, the next compaction anywhere freed the arena. (For a fiber: suspended across a compaction, resumed, and a map compacted while it runs.) A retired arena keeps the handles of the stacks that pinned it and is not tried while one of them is running (__lang_coro_pinners).

• ...and so a compaction under a pin does nothing. With the pin following

pointers, a suspended stack points into nearly every store, and compacting one retired the old arena and made the copy beside it: the bytes twice, for as long as the stack kept the word. mere-ruby's two thousand suspended fibers went from 6.9 s / 1.1 GB to 90 s / 6.5 GB. Compaction has no observable behaviour, so map_compact / vec_compact now leave a container where it is while a suspended stack points into its arena (a recycle still moves, since it must empty the map). The same walk also stopped being made twice: a suspended stack's coro_scan_ints gathers its pin as it goes. The benchmark is back to 6.65 s, at 1.66 GB -- what the sound pin keeps that the old one let go.

test/uaf/coro_pin_reach.mere and coro_pin_resumed.mere, ASan builds in scripts/region_uaf_check.sh, each with its poison (the reach skipped; a pinner's run not counted) going red. ⚠ The first version of the reach test stayed green under its poison: the string's address was still on the stack, in a dead frame's slot inside the live range, and a conservative pin rightly took it. The cell is made at the bottom of a 300-deep recursion now, so the copy is below where the stack pointer comes back to.

`proc_sig_noop`, `proc_sig_default`, `proc_sig_raise`, `proc_out_errno`. signal(2) and sigaction(2) move a disposition through a function pointer and a struct, so a program could only reach sigignore(2) -- SIG_IGN -- and an ignored signal STAYS ignored across exec(2). mere-ruby ignored SIGPIPE at its first pipe, every child it started ignored it too, and since the runtime dropped a write it could not make, a child loop { puts :ok } whose reader had gone printed into nothing for 94 seconds of CRuby's test_io, where ruby's child dies of SIGPIPE at once. ruby catches SIGPIPE with a handler that does nothing (a handler is reset to the default at exec) and keeps a disposition it inherited if that is not the default; proc_sig_noop is that, answering 0 installed, 1 kept, -1 refused. proc_sig_default and proc_sig_raise end a process of a signal, as an unrescued SignalException ends ruby. And __lang_write_all -- the write behind print_no_nl and print_bytes -- keeps the errno of a refused write for proc_out_errno (asking clears it), so an EPIPE is something a program can see. The proc_ family's errno slot (`proc_last_errno`) as for the others; emitted only when a program declares one of the names. `scripts/procsig_check.sh` (22 rows, in CI) runs each in the scene it is for -- nothing inherited, SIG_IGN inherited, a pipe whose reader has exited, a run that must end of the signal (exit 141) -- and four poisons (SIG_IGN for the handler, the inherited disposition not put back, the errno not kept, on both writers) each turn a row red. The third poison first went unnoticed: an un-restored handler also survives a raise, so the row that tells the two apart is a child's -- it inherits an ignore and not a handler.

`sock_pair`. socketpair(2) fills an array, so it joins sock_bind and the rest of the sockaddr family on the runtime's side: an AF_UNIX pair, both descriptors in one int (first * 2^20 + second), type 1 stream / 2 datagram / 5 seqpacket, -1 with fd_last_errno. mere-ruby's UNIXSocket.pair raised NotImplementedError, which seven of CRuby's test_io copy_stream cases met first. scripts/sockaddr_check.sh has nine more rows (82): the two ends talk, a closed end is the end of file, a datagram pair, an unknown type's EINVAL.

v0.1.588 — 2026-10-02

_Top-level functions may be defined in any order (Q-156): a function can call one defined below it, and two can call each other from separate declarations._

A top-level function could only call one written above it. The way round was to put everything in one let rec ... and ... -- mere-ruby's interpreter is a group of a thousand -- which also makes the members monomorphic in each other (Q-157), or a let fn promise per name, which almost nobody wrote (one, in four repositories).

Ast.order_toplevel runs once the top-level names are unique. Evaluation order does not move: a value keeps its place relative to every other value. A function definition, which does nothing when it is reached, is placed after the declarations it refers to (or earlier, when a value needs it), and functions that refer to each other across separate declarations become one group -- only those; a group the program wrote is never split. A value that needs a function that needs a later value cannot be scheduled and is left as written, with the unbound variable it always had. mere fmt prints the source order.

A program with no forward reference comes back exactly as it was, so nothing that compiled before changes: every .mere in the repository and in 18 downstream projects emits byte-identical C, LLVM, Wasm and RV32 output and the same -t answer as v0.1.587 (5,110 comparisons), and so does mere-ruby. The Q-156 probe retires. test/parity/toplevel_any_order.mere (203 programs) and four unit tests.

v0.1.587 — 2026-10-02

_mere fmt keeps the comment at the end of a constructor's line (lost comment lines 43 -> 26), and bytes_of_str is a view instead of a copy while no region block is open (Q-117)._

fmt (Q-154). A type written one constructor per line was printed on one line, and the comment at the end of a constructor's line had nowhere to go: a Top_type carries no positions. The parser now records the line of each constructor, and a type with a comment on one of them is printed one constructor per line with the comments back; every other type prints exactly as before. The gate's count also stopped counting // inside a string literal ("http://"): a line is a comment line when // is left on it after its string literals are removed. scripts/fmt_comments_check.sh: 7,527 comment lines in the examples, 26 lost (ceiling 43 -> 26; 29 by the old count).

bytes_of_str (Q-117). A str and a bytes have the same layout on every compiled backend -- the length, then the data -- and neither can change, so the str's own memory is the bytes. A line tool that handed each line to a SIMD load (which takes bytes) copied every line to do it: 2,000,000 calls on a 200-byte line peaked at 417 MB on C, and take 1.4 MB as a view. Only while no region block is open: inside one the str may be the block's and the bytes may be returned out of it, so it is copied into the current region as before. test/parity/bytes_of_str_view.mere holds both (202 parity programs).

v0.1.586 — 2026-10-02

_A spawned thread's failure has one meaning on all four backends (Q-090): join raises it again, a detached one is a line on stderr, an unclaimed one is a line at exit, and the exit status is the main thread's. C reports leaked threads too (Q-055)._

A plugin host reached for spawn to survive somebody else's code, and the four backends gave three answers. C and LLVM ended the process from the failing thread, racing the main thread's last write: the exit status was 1 in some runs and 0 in others, and stdout was sometimes cut. Wasm printed the failure and exited 0. The interpreter said nothing. A daemon whose detached handler failed once was gone -- mhttpd and mengd both.

Now every backend gives Rust's answer:

• the thread's failure is recorded, and `join` raises it again in the

joiner -- uncaught, it is the program's failure (fail: boom, exit 1); try_or takes it;

• a detached thread's failure is one line, and the program carries on:

mere: thread 1 failed (detached): fail: boom;

• one nobody claimed is one line at exit:

mere: thread 1 failed and was never joined: fail: boom;

• the exit status is the main thread's.

C and LLVM keep a record per thread { pthread, number, state, claim, message } on a list while nobody has claimed it; the thread body runs under the failure jump, so its failure lands in the record instead of in exit(1), and the record is freed when both the thread and its handle are done with it. Wasm's workers set a flag in their own instance, so an uncaught fail there hands its message to the host instead of printing it; the host keeps the record in the shared buffer the join already waited on. detach was refused on LLVM and Wasm; it is lowered on both now. LLVM's failure-message buffer is per thread.

The record is also what the leak report reads: MERE_THREAD_REPORT=1 now works on C, LLVM and Wasm (Q-055) -- still running, finished, never joined, died: <message>, never joined (only the interpreter can say what a thread was blocked on).

⚠ One consequence: a thread waiting on a channel for a message a failed thread was going to send now waits for good -- a channel does not know its senders -- where before the failure ended the process. scripts/spawn_stack_check.sh had exactly that shape (its "a fail on a spawned thread is that thread's" case), and hung; it now has main's try_or run while the worker fails and then joins it.

And a second: a worker POOL that let a handler's failure end the worker would lose a worker per failing request and then stop answering, silently. The two pools in contrib/http (serve_rd, serve_mt) now catch a handler's failure themselves -- one line on stderr, the connection closed, the worker back for the next request -- and with_rescue is still what turns it into a 500 (scripts/http_concurrency_check.sh checks the difference).

scripts/thread_fail_check.sh is rewritten from "pin the split" to "pin the contract": four programs on four backends (spawned_fail ten times each), the report, and eight poisons -- the thread not catching its own failure, join not raising it, a detached failure not told, the exit hook not telling, on C, LLVM and Wasm. scripts/thread_leak_check.sh gains the C column (the count; the wording is printed, since it races the real clock).

v0.1.585 — 2026-10-02

_ByteBuf, read_bytes and write_bytes on LLVM and Wasm (Q-016): mgunzip now decompresses byte-for-byte the same on C, LLVM and Wasm._

ByteBuf[R] -- random-access bytes, the buffer a binary tool builds its output in -- and the two whole-file bytes builtins were C and interpreter only, so a program like mgz's mgunzip ran on two backends of four.

• LLVM: %mere_bytebuf = { data, len, cap, region, owner }, the C struct

field for field, with i64 lengths (an i32 one would make bytebuf_get bb 4294967297 a question about index 1). Allocated in the region the result type names; growth through the region's in-place grow; a bad index fails through the index-failure path, so try_or catches it with C's message. The owner field is set at creation, the two writes check it and the reads mark it shared, as on C (v0.1.575/582). read_bytes / write_bytes are the C runtime's.

• Wasm: a 16-byte header { data, len, cap } like StrBuf's, from the bump

allocator (a region block reclaims what it made), zeroed by hand (memory a block gave back is not zero), growing in place when it can and copying -- and protecting the copy -- when a block is open. One thread, so no owner check. read_bytes / write_bytes reuse the existing bytes host imports; a missing file fails catchably with the interpreter's sentence.

• Each runtime is emitted only when used: the Wasm output of 474 of 521 programs

(examples and parity) is byte-identical to v0.1.584's, and wasm_size_check is unchanged.

• Found on the way, on both: write_file_bytes did not check the 0..255

range (300 was written as 44 on LLVM, masked on Wasm). It fails with C's message now; test/parity/bytebuf_edges.mere had been asking since v0.1.279, on the two backends that refused it.

Parity: 201 programs (bytes_file_roundtrip is new: 512 bytes, every other one a zero, through a ByteBuf and back). Unchecked on LLVM 23 -> 19, on Wasm 13 -> 10: bytebuf_edges, region_bytebuf_reclaimed, region_rec_capture and (LLVM) raster now MATCH. mgunzip on a 2 MB member: identical output on all three, 4 MB peak on LLVM.

v0.1.584 — 2026-10-02

_of_json into a container is a type error at the call (Q-118), not a failure when the checkpoint is read back._

to_json writes a Vec as an array, a Map as an object and a StrBuf as a string; of_json can decode none of them -- a container has a region and an identity, and a decoder makes values. The program that met this was the one that checkpointed its state (usually a Map), wrote it without complaint, and failed reading it back: of_json: expected a variant value for Vec, at run time.

of_json, of_json_opt, of_json_like and of_json_opt_like whose target is a container -- or holds one, through a tuple, an option or list, a record field or a variant payload -- are now refused where the call is typed, naming the container and the way out (decode the contents as a list and rebuild it). A top-level binding is checked as soon as it is typed, because the interpreter runs it right after; the whole program is checked again once inference has settled targets that only a later use decides. Four unit tests.

v0.1.583 — 2026-10-02

_A curried inner function called with all its arguments builds no closures on LLVM and Wasm either (Q-142): mandelbrot takes 6 MB on LLVM (was 235) and runs on Wasm (was out of memory)._

An inner function is lifted to the top level with what it captures prepended to its parameters. The C backend has emitted an uncurried twin for it since v0.1.52 -- captures and every curried parameter in one call -- and sent a saturated call there. LLVM and Wasm had the twin for top-level functions only (Q-139), so the inner go i zx zy of a mandelbrot went through the curried chain: one closure environment per application per iteration. The same loop cost 16 bytes an iteration at top level and 104 nested in a function on Wasm; LLVM allocated 6,984,016 bytes for 96,000 iterations, and examples/mandelbrot.mere peaked at 235 MB there against C's 6 MB and ran out of memory on Wasm.

Both backends now emit <lifted>__direct beside the curried definition (which a partial application and a first-class use still reach) and send an exactly saturated call to it, a self tail call as musttail / return_call. The nested loop is 16 bytes on LLVM -- the whole run -- and 16 B/iter on Wasm, equal to the top-level loop (Wasm boxes floats). mandelbrot: LLVM 6.2 MB, Wasm runs, output identical to C.

scripts/inner_direct_check.sh measures it on all three compiled backends: the nested loop against the top-level one, and a partial application that must still give the right answer. MERE_NO_INNER_DIRECT=1 turns the twin off on every backend, and --poison uses it: C 10 MB, LLVM 7 MB, Wasm 10 MB.

v0.1.582 — 2026-10-02

_The rest of Q-179: a read by another thread freezes a container, an OwnedVec is moved rather than shared, sync type cannot vouch for a Map, a stateful --lib refuses overlapping calls, and the interpreter checks a program that spawns before it runs any of it._

v0.1.575 failed a container WRITTEN by a thread other than the one that made it, and left reads free so a table built once could be read by every thread. That left the race it could not see: the owner writing while another thread reads. A Map churned by its owner under a reader segfaulted 3 runs in 3 on C; a Vec compacted under one was a use-after-free.

• Freeze on first foreign read (interpreter, C, LLVM). The first time a

thread other than the owner reads a container, it becomes shared -- a bit in its owner field, so a write needs no second test -- and a shared container is read-only for good. The owner's next write fails with its own sentence (a Map another thread has read was written). The four races, 20 runs each on every backend that builds them: 200 of 200 fail by name, no signal. A table built once and only read still works. The rule refuses "threads read it, are joined, then the owner writes" -- the same answer the static check gives a captured container. A range-check-versioned loop's unchecked reads leave no mark and need none: its guard reads the Vec's length through the checked vec_len.

• OwnedVec has an owner. spawn gives away the OwnedVecs its closure

captures (the move the type check allows) and the new thread takes them; any other thread's use fails by name. Two threads pushing to one through a launcher's parameter used to lose elements or abort.

• `sync type` cannot hold a builtin container. The marker vouches that a

type is safe to share; a Map, Vec, StrBuf, ByteBuf, ListBuf, OwnedVec, File, ThreadHandle or Coro inside it (through tuples and unmarked user types) has no lock for it to stand for, and is refused at the type's line. No program in the repository or downstream used sync type.

• `--lib` with module state refuses overlapping calls. A library whose entry

file has a top-level container returns MERE_FAIL for a call that overlaps another thread's, naming why; four host threads filling a top-level Map had kept 191,819 of 200,001 entries. A library without module state still takes concurrent calls.

• The interpreter checks, then runs. It typed and ran each top-level let

in turn, and the borrow and spawn-capture checks came after the last one -- so race_global, which every compiled backend refuses to build, ran its race on the interpreter first. A program that spawns is now checked whole before any of it runs (its warnings are not repeated).

scripts/owner_check.sh has eight new programs and nine new poisons (a read leaves no mark, the write does not say why, the guard's vec_len leaves no mark, OwnedVec use unchecked, spawn does not give the OwnedVec away -- on C and LLVM); scripts/lib_check.sh a stateful library under four host threads.

v0.1.581 — 2026-10-02

_A thousand-member let rec group stops costing a walk of the whole program per member: mere-ruby checks in 1.8 s (was 7.7) and emits C in 14 s (was 113)._

mere-ruby's interpreter is one let rec ... and ... group of about a thousand functions, and four passes were quadratic in it:

• The typer found a variable by walking the environment, and inside the

group the environment is every binding so far plus the group -- 4,226 names, 1,184 steps per lookup on average. While a group of 32 or more is inferred its environment is indexed once (Env_index); a lookup walks only what was consed in front of it (the member's own parameters and lets) and then asks the table.

• The move checker walked the same kind of list, and uses the same index.
• The unused-binding warning (mere check) resolved names in a list too; it

is a map now (2.2 s at 25,600 top-level lets, 0.25 s at 16,000).

• The C, LLVM and Wasm instantiation search asked, for every function on

every pass, for its uses -- and each asking walked the whole program and every resolved body. One walk now indexes each body's uses by name, in the order and with the shadowing the walk had, and the question reads that.

Ast.walk also compresses the chains it follows (a link is only ever set on an unbound variable and never undone, so this changes no answer).

Nothing a program means changes, and that is checked rather than argued: every .mere in the repository and in 18 downstream projects emits byte-identical C, LLVM, Wasm and RV32 output and the same -t answer as v0.1.580 (5,045 comparisons), and so does mere-ruby (92 MB of C). mere-ruby: check 7.73 → 1.77 s, -t 10.5 → 2.8 s, -c 113 → 14 s, -ll 131 → 6.1 s.

scripts/infer_scaling.sh measures the group now, with -t and with -c, and the independent bindings under check. v0.1.580 fails it (64x and 66x for 8x the members); this release is 7-8x.

v0.1.580 — 2026-10-02

_parity.sh stops counting a miscompile as "unsupported", and the two it was hiding are fixed (Q-198, Q-199)._

A parity row whose backend refuses at emit time is UNSUP and passes, because a backend that does not implement a builtin yet is a documented limit, not a bug. The test for "refuses" was the word unsupported in the error -- and the LLVM and Wasm backends put that word in front of every codegen error they raise. So unbound variable: p on LLVM read as a documented limit. emit_kind now names the sentences that mean "not implemented here" (no lowering yet, not in the codegen subset, not available on Wasm, a region loop, ...) and anything else is a failure. Two rows went red at once.

An inner function's name met a variable of another function's (Q-198): an inner let rec cnt in one function and a plain let cnt = vec_new () in another lifted as one symbol, and LLVM -- and Wasm in a variant -- read the variable inside the other function's closures as the lifted function. mgz's inflate and deflate both have the shape (p, cnt); a captured variable named len failed the same way. The pass that renames colliding inner functions knew only other function names; it knows every variable's now. Three parity cases (200 in all).

A closure that calls an inner-lifted function, on Wasm: the lambda did not carry the callee's captures, so a closure written inside a region block that calls such a helper failed "inner-lifted capture v not in scope" -- the C backend's fix from v0.1.453, never ported. It had been in parity since then, counted as unsupported. It carries them now, and msha's sha1 builds on Wasm -- and so do four contrib libraries contrib_ctest.sh had pinned as Wasm gaps for the same sentence (font/font, html/entities, html/tokenizer, proto/gen), which are unpinned: a pin that starts passing is a failure there.

v0.1.579 — 2026-10-02

_v0.1.575's owner check made a versioned loop 2.8x slower once a thread existed; it is asked once per loop now._

v0.1.575 put the write-owner check into every write, the unchecked ones range-check versioning makes inside a loop included. Its A/B measured programs that never spawn -- where the check is one load of a global -- and stopped there. Once any thread has been started the check reads the thread id, which on Darwin is a call, and it is a branch out of the loop that kept clang from vectorizing it: axpy with a join (spawn ...) in front took 0.24 s where v0.1.573 took 0.09.

The unchecked writes carry no check now. The loop's guard -- evaluated once, before the fast copy -- asks __vec_owned of every container the fast copy WRITES, and a thread that does not own one takes the checked copy, whose vec_set fails by name as before. axpy with a thread started is 0.08-0.09 s on C again; LLVM 0.20 s (0.18 at v0.1.573). vec_reverse, vec_sort and lb_to_list write too and were not checked at all; they are, on the interpreter, C and LLVM. owner_check gains a reverse case and a versioned-loop case, and a poison that makes the guard stop asking.

And a guard that was refusing loops it should have taken: with a stride above one that lands on the bound exactly, the last index visited is N - stride, not N - 1, but the guard asked N - 1 + w <= len -- so a stride-2 loop over an exactly-sized Vec never took its fast copy. axpy_simd: 0.11-0.13 s to 0.08-0.09, same output. range_version_check holds both sides of that edge: a stride-2 loop over an exact Vec is dispatched, and one over a Vec a slot short fails at the same index as before on every backend.

v0.1.578 — 2026-10-02

_The self-hosted lexer reads every reserved word as a keyword (Q-153), and the new gates are in CI._

contrib/parser/lexer.mere read twelve of the words the compiler reserves -- view, region, import, trait, impl, derive, signature, drop, using, open, for, dyn -- as identifiers, and its parser matched TIdent "import", so a program the compiler refuses (a reserved word used as a name) went through it. They are one token now, TKw with the word, and the parser's two places that read import and region by name read the keyword. scripts/selfhost_lexer_keywords_check.sh (CI) DERIVES the list from lib/lexer.ml's keyword table, as the operators' gate derives operators, so a word reserved later is asked about without anyone remembering; its poison plants a word the self-hosted lexer does not know.

CI also runs owner_check (v0.1.575), lsp_coalesce_check and lsp_folding_check (v0.1.576). The README's test count is 2882.

v0.1.577 — 2026-10-02

_mere fmt keeps 50 more trailing comments: 93 lost lines over the corpus become 43 (Q-154)._

Two places, neither needing an end position. The first branch of an if chain did not take its trailing comment while every later branch did -- one call fmt_else_chain makes and fmt_if_multiline did not (26 lines). And a comment written after the ; that ends a declaration is now attached there, the last line the declaration's tree reaches standing in for its end (24 lines); where a closing delimiter sits alone on a later line the stand-in is short of the real end and the comment is left where it was, which is what happened to all of them before. fmt_comments_check's ceiling is 43; fmt_roundtrip still finds every formatted file re-reads and formats to itself. What is left is classified in the gate: variant lines in a type, let ... in, list literals reflowed across ,, nested if/else, and // inside strings.

v0.1.576 — 2026-10-02

_The language server stops re-checking keystrokes that are already out of date, and answers folding (Q-023, Q-147)._

Every didChange re-checks the whole program, and on mere-ruby's main.mere (44k lines, 93k with imports) a check takes 10.5-10.7 s. The server handled messages one at a time, so N keystrokes queued N checks -- a word typed bought a minute of diagnostics for text that no longer existed. A didChange carries the whole document, so a later one for the same file makes it worthless: before a didChange is handled, the messages that have already arrived are read, and an unbroken run of didChanges for one document is handled as its last. Nothing else moves -- a request between two changes is answered against the text it was asked about. Knowing what has "already arrived" needs the bytes in a buffer this code owns (an in_channel can hold a whole message that select does not see), so the server reads its own input now. scripts/lsp_coalesce_check.sh (CI): ten changes sent at once are two publishes, not eleven; a hover between two changes sees both checked; the same ten changes paced 0.3 s apart are eleven, which is the control that says the count counts.

textDocument/foldingRange is answered: a top-level declaration that spans lines folds, and so does a run of two or more comment lines. A declaration has no end position, but the parser knows where one ends -- the tokens one call of parse_decls consumed are exactly one declaration -- so it keeps each one's first and last line for the file being parsed (Parser.decl_spans), at no cost beyond walking the tokens once. scripts/lsp_folding_check.sh (CI) holds a three-line declaration and a comment run folding and a one-line declaration not.

v0.1.575 — 2026-10-02

_A container written by a thread other than the one that made it stops the program by name (Q-179 stage 2)._

v0.1.574 follows what a spawned thread reaches through functions whose definitions the program shows. A closure that arrives as a PARAMETER is not one of those, and that is the shape mere-blog's race had: its handler was handed to http_serve_mt_ctx, which spawns it, and the handler pushed to a Vec the program's thread made.

So Map, Vec, StrBuf, ByteBuf and ListBuf record the thread that made them, and a write from any other thread fails with one sentence, the same on the interpreter, C and LLVM, instead of hanging a probe loop (a Map filled from four threads, three runs in three) or losing entries (159,123 of 160,000). Reads are not checked: a table built once and only read is shared safely, and a read is the hot path.

What it costs. The program's thread is thread 1 and nothing asks a thread its number until something has been spawned, so a program that never spawns pays one load of a global per write -- on Darwin a thread-local read is a call, and vec_set sits in inner loops. On benchmarks/ (C, median of 21 runs on a loaded machine) crc32 is +1.4%, wordfreq +4.4%, the rest inside the noise; every output identical. The interpreter checks the same writes with the domain id. A --lib build turns the check off at mere_lib_init: a host calls in from whichever thread it likes, one call at a time, and module state is written from each. OwnedVec is single-owner by construction and is not checked.

The struct sizes the LLVM runtime had written as numbers (24 for a Vec and a StrBuf, 32 for a ListBuf) are computed from the types now that the types grew. scripts/owner_check.sh (CI) runs a Vec, a Map and a StrBuf written through a parameter on all three backends, plus a program that shares a read-only table and must still run; its poisons take the check out of the emitted C and LLVM.

v0.1.574 — 2026-10-02

_A spawned thread is checked for what it REACHES through functions, not only what it mentions (Q-179)._

A function's type says nothing about what the function touches (TyArrow _ -> true in both is_send and is_sync), so spawn (fn () -> effect "x") with effect pushing to a top-level Vec was accepted. mere-blog shipped exactly that: eight HTTP workers pushing to one Vec, and the same push from eight spawned threads kept 159,123 of 160,000 entries (that standalone shape is refused now). Q-080 recorded the hole in 2026-08, and it was left open while mere-ruby's fibers depended on it; they have run on coroutines since 2026-09-28.

Now every function the spawned expression mentions whose definition the program shows -- a let or let rec binding, a partial application of one, a data literal holding one, a module member -- is followed to what it mentions, and a value that is not Sync at the end of that walk refuses the spawn. The message names the path (through w > fill > put), because the offending binding is usually several calls from the spawn.

A container nothing writes is shareable: if every occurrence in the program is the first argument of a read builtin, threads may read it together. mengd's inflate tables -- built with vec_of [...] at the top level, read by a thread per connection -- are that case, and nothing in them changes. (Range-check versioning turns a proved vec_get into __vec_get_unchecked before this pass runs, which made the tables look written until that name was on the list.)

What it does not see is a function value whose definition is not visible -- a parameter, a channel's message, a call's result -- so a library that spawns the handler it was given is not checked at its spawn. mere-blog's race is that shape: its handler reaches the Vec, and the handler is handed to http_serve_mt_ctx, which spawns it. Its pre-fix source is still accepted here; it was fixed in that repository (2a1bc87), and a run-time check is the next stage for exactly this reason. Nothing in the 712 programs of this repository or the 19 downstream repositories is refused. The test that pinned "a Map inside a captured closure is not seen" as accepted pins it refused; its neighbour, the parameter case, stays accepted and says why. A program with no spawn skips the pass (mere-ruby's check: 7.97 s before, 7.91 after).

v0.1.573 — 2026-10-02

_spawn checks what any argument mentions, and a ByteBuf is not shared across threads (Q-179 stage 0, Q-197)._

spawn's capture check looked at one shape: a lambda written in place. Every other argument went through as an ordinary application -- spawn (w slot), a partial application whose argument is a Map, was not looked at at all, and four threads filling one Map that way hung the C build in three runs of three (a concurrent resize breaks the open-addressing probe loop). Now any argument is checked for what it mentions, the way a lambda's captures are: spawn (w slot) is refused with the sentence a captured Map already got. A function value alone (spawn body) still passes -- an arrow type says nothing about what the function reaches, which is the next stage's question (Q-179).

ByteBuf was missing from the Send and Sync classifiers' container case while the value restriction and the region list had it, so a top-level ByteBuf written by a spawned lambda was accepted as shareable. All three now read the one list of region-parameterised containers. Nothing in the 311 examples or the 19 downstream repositories was relying on either.

v0.1.572 — 2026-10-02

_An annotation's region name is a variable unless a block of that name is open around it (Q-196)._

fn (b: ByteBuf[R]) -> .. is how the documentation writes a function over any buffer -- patterns.md says to "write R as a type variable", the tutorial shows fn (v: Vec[R, int]) -> vec_len v -- and it was not one. The name went into the type as the region NAMED R, and that is the region of every region R { } in the program. Pass a buffer to such a function, open an unrelated block called R later in the same function, and the compiler said the buffer escaped R.

mengd and mtar have done exactly that since they were written, and stopped compiling at v0.1.564: that version made a let-bound ByteBuf stop generalizing (Q-193, a soundness fix), which had been hiding the collision. A Vec, never generalized, failed the same way in every version. Neither repository was in test/downstream/REPOS, so nothing here said so for eight versions.

Now an uppercase region name in an annotation -- a parameter's or (e : t) -- names a block only when a block of that name is open around the annotation; otherwise it is a variable, one per name within the annotation, as 'r always was. Inside region R { } an annotation's R is still that block, and a container annotated with it still cannot leave it. mengd and mtar as they were written compile again (both have since been changed to 'r, which means the same thing on every version). The two tests that pinned the old printing -- (Vec[R, int] -> int) for an annotation outside any block -- print the variable now, and the tutorial and patterns.md say which is which.

test/downstream/REPOS gains mengd, mtar, mvm, mhttpd and mreg (nineteen rows), and test/downstream/CC compiles all five.

v0.1.571 — 2026-10-02

_The downstreams' emitted code is compiled now, and the first run found two LLVM bugs._

downstream_check asks whether mere -c succeeds in each of fourteen repositories; nothing asked whether a C compiler then accepts what came out. The runtime is text pasted into every program, so a change to it reaches every downstream at once and every gate that stops at emission is blind to it -- v0.1.566-567 shipped such a change and a mere-ruby build went looking.

scripts/downstream_cc_check.sh (CI) compiles each repository's emitted C with that repository's own flags (test/downstream/CC), and the LLVM IR of the four the LLVM backend emits whole; nothing is linked, so only headers are needed. A failure says which of three things it was -- a compile error, a timeout, or a kill (signal 9 is usually the out-of-memory killer; mere-ruby and mbrowse peak at 6-7 GB) -- and --poison holds each sentence to its cause. A row whose code, compiler and flags hash to an earlier pass is reused rather than rebuilt (the hash is of the code, not of which files a commit touched), which CI keeps in a cache. Each row prints its seconds.

Its first run failed one row: mwasm's LLVM IR did not build (use of undefined value '@mere_vec_int_get'). The positioned-file runtime calls the Vec[int] helpers, and file_openrw, file_size, file_fsync and file_close pulled that runtime in without registering the instance, so a program whose only file builtins were those had no helpers to call. The instance is now decided once from the runtime blocks being emitted. Built, mwasm then failed "out of memory" on its first ++: args () handed out argv's own pointers, from when a str on this backend was a plain NUL-terminated pointer, and strs have carried a length header since -- str_len of the argument hello was 32194994947519841. Arguments are copied into the default region now (never freed, so a region block around the caller cannot take them away). mwasm built on LLVM prints what it prints on C. scripts/llvm_host_args_check.sh (CI, poisoned) holds both.

And it found what killed clang in v0.1.566-567. The first full run reported mere-ruby's row as a compile error, and it was not one: clang's driver survives when its frontend is killed and exits 1 itself, printing Killed: 9 -- the gate reads that message now. What killed it is in a log: mere-ruby's mspec/rss_guard.sh, which a test sweep runs beside it, kills -9 any process over 6 GB whose command line contains mere-ruby, and a clang compiling .../mere-ruby.c peaks at 6-7 GB. The guard logged that clang's whole command line. v0.1.569 said nothing on record explained the kill of 2026-10-01; this is the explanation that fits it (the same file, the same signal, a sweep running), though that night's log is not there to say so. The gate names its temporary files after the row, not the repository.

The budget the plan had for peak RSS is not here: the same compile's peak moved by a fifth between runs on a loaded machine, and a budget that flaps is a gate nobody reads.

v0.1.570 — 2026-10-02

_mere -c --region-sites: which source lines filled the default region._

The default region is never given back, and a container goes there when nothing decided its region -- most often a buffer a function makes and uses but does not return, so it is in no type (Q-134). MERE_REGION_STATS could say how much went there, not from where. mgit's default region was 11.5 GB; finding that 8.3 GB of it was one line, mgz's 64 KiB inflate window made once per git object, took 23 rebuilds with one allocation site at a time moved to the current region.

Compiled with --region-sites, each container the program sends to the default region gets a region of its own named after its source line, which forwards every allocation to the default region (the forwarder v0.1.563 introduced) and counts what passes through it -- the struct, the storage, every growth and every copy stored into it. MERE_REGION_STATS=1 then lists the lines, most bytes first: mgit's list starts mgz/inflate.mere:341: alloc_total=8347724352, in one run. Where memory lives does not change, so the output and the default: total are the same with the flag and without it; without the flag the emitted calls are what they were (the runtime carries the forwarding check either way, a branch on a field __lang_region_live already reads). C backend only.

scripts/region_sites_check.sh (CI) holds all three on a small program of mgit's shape and goes red when a line is not charged or keeps its own memory. It was run on the CI image before it was pushed.

v0.1.569 — 2026-10-02

_Four gates that answered for their environment, and a correction to v0.1.568._

CI was red from v0.1.563 to v0.1.568, every time on one line: region_uaf_check --poison said the LLVM poison for kept_then_written stayed green. The poison frees a region struct the fix keeps, and whether the program then notices is the allocator's business: on macOS the freed bytes are reused and the output goes wrong; on glibc they are still there and the writes land in live memory. The poison now fills the struct with 0xAA.. before it frees it, and goes red on both (a segfault on Linux, a hang the gate's alarm ends on macOS). Poisons can be written as perl: expressions, which can add a line where sed cannot. MALLOC_PERTURB_ was tried and is not enough. The gate is run on the CI image before it is pushed this time; v0.1.563 added it without that.

tty_raw_check's Ctrl-C leg failed whenever the gates were started from a background job: a non-interactive shell starts & jobs with SIGINT ignored, an ignored signal survives exec, and the program under test never died of the Ctrl-C it was sent. Its pty driver restores SIGINT in the child, and scripts/bounded.sh restores SIGINT and SIGQUIT for every command it runs. Load had nothing to do with it: 24 of 24 runs failed started with &, and 24 of 24 passed with SIGINT restored, under the same 30 busy loops.

fmt_comments_check read fmt_roundtrip_check's probes: the latter writes examples/__fmtroundtrip_$$__.mere next to each example and deletes it, the former globs examples/*.mere, and _ sorts first -- so POISON 6's "first example that formats" was sometimes a file that was about to vanish, and the plain legs counted 289 files or died of a syntax error on an empty count. The probes are dot files now (.fmtroundtrip_$$.mere), which no *.mere glob picks up -- the shape other gates already use. Four other gates glob examples/ and are covered too.

downstream_check gives each repository 900 s instead of 420, and prints how long each took. v0.1.568's CI failed a second way: mere-ruby's main.mere outlived 420 s. The same mere-ruby commit had taken 222 s in v0.1.567's run fifty minutes earlier, and v0.1.562 and v0.1.569 emit it in the same time here (120 and 123 s of CPU) -- the runner, not the compiler. mere-ruby is about three times the size it was when 420 was chosen, so the margin had already gone.

The reason v0.1.568 gave is withdrawn. It said the inlined pool check made clang -O2 get killed on mere-ruby's C "every time". That was seen twice, while the full gate sweep and a simulation ran on the same machine; clang peaks at 6-7 GB on that file. On a machine doing nothing else the C that v0.1.567 emitted compiles and links (187-206 s, 5.2-6.0 GB peak, three ways), and nothing on record says what killed it. The noinline stays -- it costs nothing measurable and keeps the pool out of every creation site -- but it fixed nothing that was shown to be broken.

v0.1.568 — 2026-10-01

_mere-ruby builds again: the stack pool's size check made clang -O2 give up on it (v0.1.566-567)._

v0.1.566 made a pooled stack carry its size and the pool check it on the way out, a call to __lang_fail_impl (which does not return) inside the take loop. Inlined into every coroutine creation, that sent clang -O2 over a cliff on mere-ruby's 93 MB of emitted C: the compiler was killed after 136 s, every time, where the same file without the check compiles in 168 s. Nothing in this repository's gates compiles a downstream's C -- downstream_check asks whether mere -c succeeds -- so it shipped twice; a build of mere-ruby against v0.1.567 is what found it. The pool functions and the failure path are out of line now (noinline, C and LLVM): the pool is not the hot path, and churning 64 coroutines at a time costs what it did (0.06 s for 2000 rounds). mere-ruby builds in 164 s and its corpus matches.

v0.1.567 — 2026-10-01

_A recycled or compacted container that escaped its block lost its struct (Q-195)._

A Map or a Vec can move its storage to an arena of its own -- map_recycle, map_compact, vec_compact -- and after that its region names that arena, while the struct the handle points at still lives where it was made. Runtime retention (v0.1.557) decided from region alone: for a map made in region R { }, recycled, and captured by a closure that outlived R, it saw an arena that is not a block, did nothing, and R was freed under the handle (the closure's next write segfaulted on C). A Map and a Vec now carry home, where their struct lives, and their copier keeps both. LLVM has no map_recycle or compaction and is not affected.

Found by simulating Q-134's proposed fix -- every container whose region nobody decided placed in the runtime current region instead of the default one -- on mere-ruby, whose frame pool recycles every map it hands out: corpus program 100 segfaulted, a bisection over the 1,867 allocation sites and AddressSanitizer (with the region cache off, so a freed block is really freed) named the route.

region_uaf_check gains recycled_escape and a poison that drops the home retention; ROUTES gains its row.

v0.1.566 — 2026-10-01

_coro_new_sized, and a stack pool that follows the program's peak instead of stopping at 16._

The pool. A finished coroutine's stack was kept for the next one, up to 16 per thread; past that every coroutine paid an mmap, a guard mprotect, a first-touch fault and a munmap, about 10 us. A server with fifty connections in flight is past it whenever more than 16 finish together -- the likely cause of mpoll_coro making a coroutine per connection serving fewer requests than its worker pool. A list now keeps up to the most coroutines the thread has had alive at once (at least 16). That is memory the program already had at its peak, so the peak does not rise; the pool only stops giving it back below it. madvise on the way in was measured and left out: 0.6 s more for no RSS saved on stacks that touch a page or two.

`coro_new_sized : int -> (Coro['m] -> 'm -> CoroExit) -> Coro['m]` makes a coroutine on a stack of at least that many bytes, rounded up to a power of two of at least 64 KiB, at most 1 GiB; the pool keeps one list per size. Only the pages a stack touches are resident, so a small stack saves address space rather than memory -- for a program that keeps very many coroutines alive, or a big one for one that recurses deeply. Overflowing a small stack is named like any other. Rewritten before type-checking like coro_new (partial application and the bare name included); interpreter, C and LLVM; Wasm and RV refuse it by name.

LLVM maps its stacks with mmap, as C does (the flags are Darwin's or Linux's, told apart at run time by the weak symbol the overflow handler already uses). posix_memalign made a page resident for every stack before anything ran on it, so a suspended coroutine cost two pages on LLVM and one on C: 10,000 of them were 335 MiB against 171. They are the same now (164 MiB).

coro_check gains sized (both sizes, a partial application, a size refused), sized_overflow and sized_reuse -- a small stack finished first must not be handed to a coroutine of the program's own size -- with a poison on each backend that makes the pool ignore the size. A pooled stack carries its size beside the pool's link word and taking one checks it: a stack of another size would put the stack pointer outside its mapping, and what that does depends on what is mapped there -- the first version of this poison stayed green in one full run out of two, which is how that was found.

v0.1.565 — 2026-10-01

_A finished coroutine keeps nothing on LLVM either: generational handles and an env of its own, the C runtime's v0.1.558._

On C, v0.1.558 made a finished coroutine free everything (Q-183). LLVM still handed the program the record's address, so the 24-byte record could never be freed, and a body's env went to the default region: a million coroutines made and finished held 33.7 MiB, and 49.7 MiB when the body captured something.

Now a handle on LLVM is what it is on C -- a slot and a generation, 24 bits each, below 2^48, resolved through a per-thread slot table -- and reaping frees the record and bumps the slot's generation, so a handle from before answers "has finished". Coro and CoroExit are i64 in the IR (the message word needs no conversion for a Coro any more). The lambda written as coro_new's argument has its env malloc'd as the coroutine's own and freed when the body ends; any other closure's env is where it was.

coro_check's LLVM cap drops from 128 MiB to C's 16 MiB, gains a poison that keeps the record (47 MiB, red), and its finished-check poison now removes the check that a stale handle resolves to nothing.

v0.1.564 — 2026-10-01

_The last inner-function shape reaches its caller's region, and a let holding a ByteBuf is not generalised (Q-193): mgit's never-freed allocation drops from 34.7 GB to 11.5 GB._

v0.1.562 gave inner functions region parameters of their own and left one shape out: an inner function of one member of a let rec ... and group calling another member. That is the shape of mgit's object store -- store_read reaches loose_read through an inner in_packs, and the three are one group -- so mgit's reads still went to the default region.

The group's marks. When an inner binding is generalised, a region variable it does not quantify belongs to something that outlives it, and its "allocation" mark is removed so a call site inside a block cannot decide it. A group's own variables are in that position too -- they appear free in an inner function of a member -- and losing the mark meant the group could not make them region parameters. Now a variable keeps its mark when it is the group's: level 1 or deeper, and in the type of a let rec group still being inferred (both places that infer groups -- the typer's Let_rec and the pipeline's top-level infer_top_rec -- say which those are). Every other variable is unmarked as before. v0.1.562 tried keeping every mark, and a call inside region BLK then decided a region that mere-ruby's benv shares with a global pool; those are level 0, and this rule leaves them alone.

ByteBuf in the value restriction (Q-193). A let is generalised unless its type mentions a mutable container, and the list had Map, Vec, OwnedVec, StrBuf, Channel, ListBuf and Coro, and not ByteBuf. So in let (out, _e, ok) = zlib_inflate raw hp in, out's region became a fresh variable at every use, and the region the inflater allocated the buffer in was decided by nobody: the default region. The same program written with a Vec passed the caller's region.

Neither alone moves mgit; together, counted by the runtime on the Mere repository (17,505 objects, output identical to git):

What is left in the default region is what no function's type names -- mgz's Huffman tables and bit readers, made and dropped inside the inflater. That is Q-134 proper.

region_params_check asserts all four inner-function shapes as ^param down to the emitted calls (four on C, four on LLVM) and a ByteBuf let (test/regionparams/bytebuf_let.mere); both go red on v0.1.563.

Swept, with imports resolved, against v0.1.563: 982 files compile under both, none differently; 111 compile under neither (unvendored imports, deliberate refusals) and are not counted. mere-ruby's main.mere compiles under both. (The sweep v0.1.559 reported -- 1,072 files, no difference -- measured nothing: it timed each run with timeout, which this machine does not have, so every file exited 127 under both compilers.)

`mere install` names the other cause of an integrity error (Q-194). Before v0.1.400 a package's content hash covered the installed tree's .git, which is different in every clone, so a lock entry written then fails on every fresh clone with "content changed since mere.lock". Four repositories had such entries (their hash lines are re-computed now; the revs did not move). For a whole-repository package -- a subdir never had a .git to hash -- the error now says so, and that deleting the lock and installing again keeps the revs, which mere.toml pins.

v0.1.563 — 2026-10-01

_Four use-after-frees the types could not see: a retained container written after its block, a thread's env, an OwnedVec element, an LLVM channel message._

All four were accepted by every backend and safe by every verdict in test/escape/ROUTES, and all four read or wrote freed memory once the block's arena had been reused. They were found by enumerating, route by route, what can reference a value after its block ends -- the survey that R2 (Q-134) needs before it can put more allocations in blocks.

A container retained by v0.1.557, written after its block (Q-190). v0.1.557 fixed the closure route (Q-188): a container captured by a closure stored somewhere older marks its block "kept", and the block's memory is handed over instead of freed. Then the block's struct was re-initialised and put back in the cache -- but the escaped container still names that struct as its region, so a later vec_push allocated in whichever block took the struct next, and was freed with it. The witness for v0.1.557 only READ the value afterwards, which is why it passed. Now a kept block's struct is never reused: it stays as a forwarder to the region that adopted its memory, and allocation and growth through it follow the forward (C: fwd; LLVM: field 5, and the struct is no longer freed). One struct per kept release is the cost.

A thread spawned in a block (Q-191). spawn handed the thread its closure's env as it was; a str captured inside region R { } was read by the thread after R was reused. The thread now gets a copy, in the default region, through the env's copier -- as coro_new does since v0.1.558. (LLVM cannot express this today: detach and a block returning a ThreadHandle are unsupported there. It marks the open blocks kept, the conservative form it uses for closure stores.)

An OwnedVec element (Q-192). An OwnedVec is malloc'd and outlives every block, and owned_vec_push stored the element as it was. It is copied into the default region now, on C and LLVM, as every other container copies what it stores into its own region.

An LLVM channel message. The C backend copies a message into the message's own region; LLVM sent a str as the pointer it was, and the receiver read the churn's bytes. It is copied into the default region now.

scripts/region_uaf_check.sh (CI) runs each route after forcing reuse and compares with the interpreter on C and LLVM; --poison undoes each fix in the emitted code and must go red (six poisons). ROUTES gains the four routes as SAFE rows and bytebuf_out as GATED (the region-escape rule refuses a ByteBuf out of its block; the codegen-side container check does not list ByteBuf, and this row is what says the type rule covers it).

v0.1.562 — 2026-10-01

_An inner function takes region parameters of its own._

A top-level function's allocations follow its caller's region (v0.1.464): the region travels in as a leading argument of its __direct twin. An inner function's did not -- a let rec in a body, a let-bound lambda, a lift inside a lift -- so whatever it allocated, and whatever the functions it called allocated, went to the default region even when the function around it had been handed a block:

let pr = fn (n: int) -> let v = vec_new () in let _ = vec_push v n in v;
let sr = fn (n: int) ->
  let rec ip = fn (k: int) -> if k == 0 then pr n else ip (k - 1) in
  ip 2;
region R { let a = sr 5 in ... }   // a's Vec: R now, the default region before

The typer already quantified an inner function's allocation regions and named them (it must: v0.1.559 stopped it, which took region polymorphism away, and v0.1.560 withdrew that). What was missing was a parameter to carry them and a call that passes them. Now they lead the lifted definition (and its __direct twin on C), a direct call passes what it bound -- read off the call the way a top-level call's are -- and a use as a value, through the closure adapter, passes the default region, as a top-level function's closure form does. A self-tail call stays a jump only while it hands its regions back unchanged. C and LLVM.

test/regionparams/inner.mere: an inner let rec, a let-bound lambda and a lift inside a lift now read ^param in --dump-region-params (which learned that an inner function's parameters are parameters), and region_params_check asserts the emitted calls on both backends. region_inner_poly still holds.

Not reached: an inner function of one member of a `let rec ... and` group calling another member. The group's region variables are unmarked when the inner binding generalises, because a marked variable it does not quantify might equally belong to an enclosing value, and then a call inside a block would claim it -- keeping the marks made mere-ruby's benv a region BLK value again. Telling the two owners apart is a change to generalisation. It is also the shape mgit has (store_read reaches loose_read through an inner function, in one group), so mgit's reads are unchanged: 33.7 GB of its allocation still goes to the default region, counted by the runtime.

v0.1.561 — 2026-10-01

_A coroutine transfer carries a value, typed by the one that receives it (Q-184)._

coro_new      : (Coro['m] -> 'm -> CoroExit) -> Coro['m]
coro_transfer : Coro['a] -> 'a -> Coro['b] -> 'b
coro_exit     : Coro['a] -> 'a -> CoroExit
coro_root     : unit -> Coro[unit]
coro_switch   : Coro[unit] -> unit

A switch carried nothing, so both programs built on coroutines kept a mailbox beside it: mpoll_coro a table from fd to the event bits that woke it (and a second one to hand a pooled worker its fd), mere-ruby a global slot and a kind. Now coro_transfer c v me suspends me, resumes c with v, and returns what me is handed next; a body is handed its own handle and its first message, and ends with coro_exit next v.

It is typed, and that is why `coro_self` is gone. Coro['m] is the type of what that coroutine receives. The 'b a transfer returns is the 'm of me, and the runtime checks that me is the one running -- so what arrives was checked, at the sender, against the receiver's own type: handles come only from coro_new (typed by the body) and coro_root (the thread's own stack, which receives unit). "The coroutine running now" has no type to check a sender against, so coro_self could not be kept; coro_self and the old body shape (fn () -> .. returning the coroutine to run next) are errors that say what to write instead. A let bound to coro_new .. is not generalised, like a channel, or one coroutine could be sent an int here and a bool there. CoroExit is the name of what a body returns rather than Exit, which is a name programs would want for themselves.

A message is a scalar for now -- int, bool, float, unit or a Coro. It is one word in the runtime, read by the receiver with no copy. A boxed message would have to be copied into the receiver's region, and mere-ruby's Fibers run in the default region, so every resume would allocate there. move_check refuses anything else by name, and C and LLVM check again at the type they emit.

How it is built: coro_new is rewritten before type-checking into two internal builtins -- a raw coro_new whose body is handed its handle, and a read of what was sent -- so the runtimes stay untyped and each backend reads the word back at its type with ordinary code; the literal fn me -> fn m -> .. form makes no closure beyond the user's (a wrapper would copy an env per coroutine, the default-region growth v0.1.558 removed). Interpreter, C and LLVM; Wasm and RV refuse each builtin by the name the program wrote.

The two users, moved: mpoll_coro loses both tables -- a connection is a Coro[int] handed the bits that woke it, and a pooled worker is handed its next fd the same way (verify.sh: every mode, all checks). mere-ruby keeps its mailbox, because what a Fiber passes is a Ruby value and a Ruby value is not a scalar; its coro_self became coro_root (the only stack without an entry of its own is the main one), and a finished fiber's entry is dropped last, just before coro_exit. Its corpus (267/267) and core/fiber, thread, enumerator, lazy and threadgroup are unchanged. A million switches cost what they did (0.11 s, C -O2).

coro_check has the values of each kind on three backends, the third argument that is not the one running, and the refusals: a str message, coro_self, the old shape, and a message type fixed once.

v0.1.560 — 2026-10-01

_v0.1.559 is withdrawn: an inner function is region-polymorphic again._

v0.1.559 made a region parameter reach a call made from an inner function by not letting the inner function quantify the allocation's region. That gave every inner function ONE region for all of its calls -- the enclosing function's -- and a helper called once for something that outlives a region block and once inside it is then a region-escape error:

let f = fn (u: unit) ->
  let helper = fn (k: int) -> let v = vec_new () in let _ = vec_push v k in v in
  let keep = helper 40 in
  let t = region B { let tmp = helper 2 in vec_get tmp 0 } in
  vec_get keep 0 + t;           // v0.1.559: `keep` now holds a value from region `B`

mere-ruby's main.mere has that shape and stopped compiling. The typer is back to quantifying, and the lifted body no longer captures the enclosing function's region parameter either: a closure can outlive the call that made it, and its env would then hold a region pointer whose block has been released and whose struct the runtime reuses for the next block. The emitted C for mere-ruby is byte for byte v0.1.558's again. test/parity/region_inner_poly.mere is the shape above; region_params_check pins the four inner-function calls at ? and goes red when they are taught.

What v0.1.559 was after needs the other half: an inner function taking region parameters of its own, passed at each call the way a top-level function's are.

Two things v0.1.559 said that were wrong. Its sweep of 1,072 programs found nothing newly refused because it ran without their imports resolved, so mere-ruby failed on an import under both compilers and compared equal; and the gate that would have caught it, downstream_check, reports "did not run" (exit 3) when MERE_DOWNSTREAM is unset, which a local run of every gate counted as a pass. And "mgit's peak memory does not move" was one pair of peak-RSS readings on a busy machine, where the same binary on the same input read 5.6 and 15.4 GB. Counted by the runtime (MERE_REGION_STATS=1), v0.1.559 moved mgit's never-freed allocation from 33.7 GB to 10.6 GB -- which is what v0.1.560 gives back up, until inner functions take region parameters.

v0.1.559 — 2026-10-01

_A region parameter reaches a call made from an inner function._

A function that takes a region parameter (v0.1.464) passes it to what it calls -- unless the call is made from something lifted out of its body. Then the callee got the default region, whatever region the outer function had been given:

let pr = fn (n: int) -> let v = vec_new () in let _ = vec_push v n in v;
let sr = fn (n: int) ->
  let rec ip = fn (k: int) -> if k == 0 then pr n else ip (k - 1) in
  ip 2;
region R { let a = sr 5 in ... }   // a's Vec: the default region, not R

It had two causes. The inner let rec ip generalised the allocation's region itself, so its region was a variable nothing would ever bind; and a lifted body was handed no region parameter to pass on. Now an inner binding never quantifies an allocation's region -- only a top-level function can take one, since the backends look it up by source name -- so the variable is the enclosing function's, which makes it a parameter, and a lifted body or a closure receives it as a capture, the way a block's region has been captured since Q-131. Unmarking a region the binding does not quantify is a top-level decision too, so a let rec ... and group keeps its marks.

C and LLVM both pass it: an inner let rec, a closure, a lift inside a lift, and the inner binding of a group (test/regionparams/inner.mere, four ? before, four ^param now, asserted in region_params_check down to the emitted calls; test/parity/region_inner_param.mere holds the four backends to one answer).

Found by mgit: its store_read reached every allocation through an inner function, so none of its reads took a region. They do now (0 call sites named / 1 forwarded before, 7 / 15 now), and the output is unchanged. Its peak memory is not: what it spends is zlib_inflate's buffers, made, used and dropped inside the inflater, and a region that appears in no function's type is not something an argument can reach. That is the rest of Q-134.

No program in the repository or the downstream packages (1,072 files) is refused, or compiled differently in outcome, on C or LLVM.

v0.1.558 — 2026-10-01

_A finished coroutine keeps nothing (Q-183): its env is its own, and its handle is a slot and a generation._

A server that made a coroutine per connection grew by about 120 bytes per connection for as long as it ran -- 13.9 → 23.1 MiB over 80k connections, and mpoll_coro had to write a pool of workers to stay flat. What a finished coroutine kept, measured exactly on C: its 24-byte handle record (32 with malloc's rounding) and its body's env, both for good.

The env is the coroutine's own. coro_new copied it into the default region, which is never freed. An env copier can now be given a marker region that makes the env STRUCT malloc'd -- freed when the body ends -- while what its fields point to goes to the default region as before (a captured string may be kept by something else; the struct's address never leaves it). And the lambda written as coro_new's argument is made that way to begin with, so nothing of it is ever in the default region; its captures are deep-copied into the default region as the copy would have made them.

The handle is a slot and a generation. The program held the record's address, so the record could not be freed without a stale handle switching to some other coroutine. A handle is now 24 bits of slot and 24 of generation, below 2^48 (out of the range coro_scan_ints callers number their own handles in). Reaping frees the record, the stack, the saved state and the slot, and bumps the generation; a handle whose generation does not match answers "has finished". A program keeps its peak of live coroutines.

Measured: a million coroutines made and finished hold 1 MiB (34 MiB before); the Q-183 probe retains 0 bytes per coroutine (64 before); mpoll_coro with a coroutine per connection, its body written as a lambda at the coro_new, is flat over 100k connections (3.4 / 2.9 / 3.3 MiB at 20k / 50k / 100k) with no pool. mere-ruby's corpus 267/267. coro_check.sh caps C at 16 MiB for the million and has a poison that keeps the records; poisons 5, 6 and 8 follow the new runtime. LLVM is unchanged and still keeps the 24-byte record (its cap stays 128 MiB).

Also: migration_check.sh and live_soundness_check.sh both started PostgreSQL on port 54329, so a gate runner running them at once failed one of them; migration_check uses 54330.

v0.1.557 — 2026-10-01

_A closure that leaves its region block no longer reads freed memory: runtime retention (Q-188)._

A use-after-free that every check accepted. A closure made inside region R { } and stored somewhere that outlives R kept pointing into R:

let o = vec_new ();
let _ = region R { let v = vec_new () in let _ = vec_push v 700 in
                   vec_push o (fn (u: int) -> vec_get v u) };
... blocks that reuse the arena ...
(vec_get o 0) 0     // interpreter: 700.  C: -1.  LLVM: segfault.

An arrow type names no region, so the escape check cannot see it. On C the closure's env was copied out (v0.1.290) but a captured Vec is a handle into R; on LLVM, which allocates an env in the current region and has no env copier, even a captured int read garbage. Found while planning Q-134, by reading the env copier, and confirmed by running it.

The fix is at run time, not in the types. Every store of a value goes through a copier into the destination's region (__mcopy_). A container's copier -- still an identity, containers are handles -- now asks whether the container's region is a block younger than the destination; if so, the block is marked, and its release hands its memory to the destination instead of freeing it (or, when the destination is not a block open on this stack, to a region that is never freed). LLVM has no copier on that path, so a store of a value whose type holds a closure marks every open block above the destination -- conservative, and never unsafe. Wasm already kept a callee's allocations (Q-132) and reads the right values. A wrong guess costs memory, never safety: nothing depends on the types being precise.

Measured: mere-ruby's corpus (267/267) and csv benchmark mark nothing, so its memory is unchanged by construction. MERE_KEEP_TRACE=1 prints each block that is retained and where it went. test/parity/region_closure_escape.mere holds four backends to the interpreter's answer (v0.1.556's C prints -2); test/escape/ROUTES has the route, SAFE, Q-188.

v0.1.556 — 2026-09-30

_Three small things the dogfoods walked into: Vec[__heap, T], let rec drop, and a region block before ||._

`Vec[__heap, T]` is the default region's Vec, written out (Q-185). The tutorial names __heap as that marker and int Vec expands to it, but the bracket form took only an UPPERCASE first name as a region -- so Vec[__heap, int] made a Vec whose region slot held a type called __heap. mere check and the interpreter accepted it; the C backend stopped at the vec_new that filled it ("missing Vec result type"), which is where mgit's pack table met it. __heap in that position is the region now.

A reserved word after `let rec` is named as one (Q-186). let rec drop = said "expected 'ident = expr' after 'let rec'". v0.1.538 taught the pattern position to say "drop is a reserved word"; the name after let rec is not a pattern, so it never did, and two dogfoods a month apart walked into drop.

A region block is an operand (Q-187). It is closed by its }, like a parenthesised expression, but it was parsed at the level of let and if, so region R { e } || x ended at the } and || x was a syntax error. It is parsed as an atom now. test/parity/heap_region_annotation.mere has both.

v0.1.555 — 2026-09-30

_A listener on a chosen address, bind(2) on a socket, the address a socket has, and the errno fd_ keeps._

tcp_listen binds INADDR_ANY and nothing could ask which address or port a socket had: bind(2), getsockname(2) and getpeername(2) take a struct sockaddr *, which no extern can spell. A ruby on top of this answered TCPServer.new("localhost", 0).addr with the wildcard where ruby answers ::1, could not raise EADDRINUSE or EADDRNOTAVAIL or EACCES from a bind, and read the bound port back from lsof(8). And fd_read / fd_write answer -1 without errno, so a connection the peer reset read as a bad descriptor and every refused socket write had to be called EPIPE.

The runtime keeps the sockaddr, the way it keeps struct rlimit (v0.1.550): an address goes in as the text getaddrinfo(3) reads and comes out as the text getnameinfo(3) writes, and the family comes out as a name, because AF_INET6 is 30 on macOS and 10 on Linux.

tcp_listen_at (host) (port) (backlog) -> int the fd; -1 errno kept; -2 did not resolve. "" is the wildcard sock_bind (fd) (host) (port) -> int numeric host, the socket's own family; 0 or -1 sock_local_addr (fd) -> str "inet 5000 127.0.0.1", sock_peer_addr (fd) -> str "inet6 5000 ::1", "unix 0 <path>"; "" on failure fd_last_errno () -> int errno of the last of these or of any fd_ call, 0 on success

tcp_listen_at does what ruby's TCPServer.new does (ext/socket/ipsocket.c, init_inetsock_internal): each answer of an AI_PASSIVE lookup in order gets socket, SO_REUSEADDR and bind, the first that binds is the listener, and when none does the errno is the last answer's. fd_* return what they returned before; every call now stores the errno of its own syscall in the per-thread slot fd_last_errno reads, and a refusal the runtime decides itself (a negative fd, an unknown mode, a read of size 0) is EBADF or EINVAL.

scripts/sockaddr_check.sh, 73 rows, in CI. Each row is a port the kernel gave the probe, compared with what the other end of a connection reports, or a refusal it provoked: a port in use, an address the host does not have (TEST-NET-1), a bind of a socket already bound, and a reset provoked by closing a socket with an unread byte in it after poll(2) said the byte had arrived. The errno numbers differ by platform exactly here (EADDRINUSE 48 and 98, ECONNRESET 54 and 104, ENOTSOCK 38 and 88), so the expected ones are read from the host's own <errno.h> by a C program the gate compiles. Run on macOS arm64 and on Linux arm64 and x86-64, as root and as an unprivileged user. Poisoned six ways -- errno not per thread, errno dropped by fd_*, the last answer bound instead of the first, the socket's family ignored by sock_bind, no SO_REUSEADDR, the family names swapped -- and each moved at least one row.

⚠ Three of the poisons moved nothing on the probe's first version. The wildcard row accepted :: or 0.0.0.0, which is right -- a host without IPv6 answers only the second -- and so it also accepted a listener bound to the last answer. What does not depend on the host is that a listener on a name is reached by a connect to the same name; that row catches it. The SO_REUSEADDR row needed a port in TIME_WAIT, which an RST does not leave, so it closes a connection from the server side first. And sock_bind binding "" on an IPv4 socket is only a question where :: is answered first, so that row binds exactly that.

Interpreter, LLVM and Wasm are unchanged, as for fd_*: the interpreter says it has no mock for the extern, LLVM and Wasm leave it an import.

v0.1.554 — 2026-09-30

_A gate that did not run says so in its exit status: 2 could not answer, 3 optional._

Ninety-four places in scripts/ printed "skipping" or "SKIP" and exited 0, so "passed" and "did not run" were one status. A runner had to read the words to tell them apart -- mgate did, and read three passes that count their skips ("(13 skipped)") as skips -- and the 65 gates that could not fail for a missing tool were this shape. Every one of them now says what it is:

In CI a 2 is red: tool_preflight --required says the runner has every tool the gates probe, so a gate that cannot find one is a broken runner. A 3 is not: the fifteen gates that can exit 3 run through scripts/gate.sh, which turns 3 into 0 and prints that the gate is optional and did not run. The 26 header comments that said "Skips (exit 0)" say which status they mean.

scripts/skip_exit_check.sh (CI) keeps the old shape from coming back: an echo that says SKIP, skipping or skip-ok with exit 0 on the same line or the next. Its poison plants both shapes.

These are the classes mere test (v0.1.552) and mgate already report.

Two more things the gate runs found in the gates themselves. normalize_conformance.sh wrote its scratch program into examples/ under a fixed name, and a stopped run left it there -- where it was committed once, with this machine's temp path in it. It carries the process id now, is removed on INT and TERM too, and .gitignore names it. And the first poison of skip_exit_check.sh planted a probe for a tool called frob in the usual command-lookup form, which tool_preflight --required read as a dependency of the gates -- in the comment explaining it, too.

v0.1.553 — 2026-09-30

_A table a helper builds at module init is module state under --lib, not a call's._

Under mere -c --lib every top-level function body is typed inside the call region (v0.1.455), so a helper that builds and returns a container has Vec[__call, _] in its type. Called at module init it runs outside any call and the container lives in the default region -- but the value's type still said __call, and the library-boundary escape check refused it:

let vec_of = fn xs -> ...;              // builds and returns a Vec
let tbl = vec_of (Cons (3, Cons (4, Nil)));
pub let get = fn (i: int) -> vec_get tbl i;

region escape across the library boundary: tbl now holds a value built during a call ... build it at module init -- which is what the program did. Every table mgz builds that way was refused (with carets on the functions after it, not on the table), so mpng-ruby, which links mgz into a library, had not built since v0.1.455. Found by running every downstream repository's checks at once.

A non-function top-level value's type now says __heap where it said __call: at init the call region is the default one. lib_check.sh has the case, and its store-into-module-state case is still refused.

v0.1.552 — 2026-09-30

_mere test: the checks a package declares, found and run._

Q-169 had half an answer since v0.1.520: mere doc came in, mere test did not, because the question was the discovery convention (*_test.mere? a tests/ directory?) rather than anything technical. The convention is now read off the packages that exist: of the downstream repositories with checks, eighteen have a verify.sh at their root, three have *_test.mere files, and none imports contrib/test. So:

• [test] run = ["sh verify.sh", ...] in mere.toml is the list, run in order

from the manifest's directory -- a list and not a glob, as test/contrib_ctests.txt is, because a check that should have been found and was not says nothing

• without a list, the directory's verify.sh; with neither, exit 2 and a line

saying so

• each exit status is a class, the one the gate runner mgate uses: 0 PASS, 2 CANNOT, 3 SKIP, 201 TIMEOUT, else FAIL. mere test exits 1

on a FAIL or TIMEOUT, 2 on a CANNOT, 0 otherwise

• each command sees MERE and MERE_BIN (this compiler) and, for a

checkout's build, MERE_ROOT. ⚠ The first version set MERE to the checkout, on the belief that most verify.sh files take one: run over all 21 downstream repositories it turned 14 red with "is a directory". Counted, 12 run $MERE and 9 build $MERE/_build/...; the 9 accept either now

Before this, mere test compiled a file called test -- the [_; path] arm took it. scripts/test_cmd_check.sh (CI) runs a fixture with one check per class and a verify.sh beside the list; its poison removes the list, and the check that the list ran in order is what goes red.

v0.1.551 — 2026-09-30

_Four holes the dogfoods walked into: a record named like the prelude's result, a builtin passed as a value, a region captured from the wrong side of a lift, and a gate that could not run beside its own poison._

Three new programs written against the language in one day -- a gate runner (mgate), a git reader (mgit) and a coroutine-per-connection server (mpoll_coro) -- and each stopped on something no earlier program had written.

A record and a variant sharing a name are refused. type result = { name: str } passed mere check and ran on the interpreter, and mere -c died inside the compiler: Invalid_argument("List.combine") in subst_variants, the record's zero parameters zipped against the prelude's ('a, 'e) result. v0.1.474 and v0.1.525 refused a variant redeclared with other constructors and a record redeclared with other fields; the cross case was the one left, and the name a program reaches for first is one the prelude already owns. Now: type result is declared both as a variant (Err of _ | Ok of _) and as a record ({ name }), from either order. The capability records Logger and Metrics stay replaceable by a program's own declaration in any shape, as before. Measured before landing: 0 of 1,193 .mere files in this tree and downstream are newly refused.

A builtin is a value on every backend that can apply it. list_iter hs join did not compile on C while list_iter hs (fn h -> join h) did: each backend eta-expanded builtins in value position only for the names a phase had listed. The rest are now expanded too, on C, LLVM and Wasm -- of fourteen single-argument builtins tried, twelve were refused on C and all twelve compile (is_digit, utf8_len, hex_of_bytes, print_int, file_exists, ...); on LLVM and Wasm the ten tried were refused as values while applying them worked. A builtin with no direct-call lowering comes back to the value path from inside its own expansion and is refused there, recognised by the synthesized callee's identity. ⚠ The first version guarded with a flag set around the synthesis; the expansion becomes a closure adapter whose body is emitted when the adapters are drained, the flag was down by then, and test_basic ran for an hour. test/parity/builtin_as_value.mere holds four backends to one output.

A region opened inside a lifted function is not a capture from outside it. fn -> let rec loop -> region R { let b = bytebuf_new 0 in let rec go (pushing to b) } emitted C that did not compile: use of undeclared identifier '__region_R'. The names bound inside a lifted body held the block as R, and a region travels as a capture named __region_R (Q-131), so the inner helper's capture was threaded into loop from its call site, outside the block. Both spellings are bound now. test/parity/region_rec_capture.mere.

`fmt_roundtrip_check.sh` can run beside its poison. It writes each formatted example next to the original under a fixed name, and a gate runner running the plain and --poison invocations together (mgate) found 56 and 48 "refused" files on a main that is green run by run: the two overwrote each other. CI runs one step at a time, which is why nothing had seen it. The probe names carry the process id, and cleanup removes only its own.

Recorded, not fixed: a record field annotated Vec[__heap, int] loses the Vec's element type at the vec_new that fills it (C), and a Vec of region-polymorphic records at top level is the Q-042 shape; mgit keeps its packs in parallel Vecs instead. And Q-134 has its second witness: mgit reads every object inside region R { } and peaks at 1.9 GB on this repository, because the allocations are made by the functions the block calls.

dune test 2870/0; every gate in the workflow plus the two unwired ones run through mgate, against the same run on v0.1.549: fmt_roundtrip green again, first_run green after the README's counts (193 parity programs, 2870 tests).

v0.1.550 — 2026-09-30

_Resource limits, scheduling priority and flock(2): proc_* and file_flock._

Five syscalls a program could not declare with extern fn, each for its own reason: getrlimit / setrlimit move the limits through a struct rlimit *, getpriority / setpriority take an id_t -- <sys/resource.h> is in every emitted program already, so the prototype Mere writes meets the real one and is a "conflicting types" error -- and flock is in <sys/file.h>, which is not included. Like file_* (v0.1.509) and fd_* (v0.1.522) the C is written in the runtime with the real headers, emitted only when a program declares one of the names: two headers, no library, no change to the build line.

The platform's numbers differ exactly here -- RLIMIT_NOFILE is 8 on macOS and 7 on Linux, RLIM_INFINITY 2^63-1 and 2^64-1, EWOULDBLOCK 35 and 11 -- so they stay on the C side and the runtime defines the contract:

• a resource is asked for by name (proc_getrlimit "NOFILE"), the names

ruby's Process.getrlimit accepts, present only where the platform defines them; proc_rlimit_names lists them and proc_rlimit_resource hands out the platform number for a caller that has to show it (ruby's Process::RLIMIT_*);

• a limit of -1 is RLIM_INFINITY going in and coming out;

proc_rlim_const "INFINITY" gives the platform's value in decimal, because on Linux it does not fit an int;

• proc_getrlimit takes one snapshot and proc_rlimit_field reads soft or hard

out of it -- file_stat's rule, so the two limits come from one moment;

• the priority selector is 0 process / 1 group / 2 user, and the lock bits are

1 shared / 2 exclusive / 4 non-blocking / 8 unlock;

• file_flock answers three ways: 0, 1 when the lock is held elsewhere

and the caller asked not to wait (ruby's false), -1 otherwise.

errno is kept, which the earlier families do not do. getpriority answers -1 for a process at priority -1, so its failure is visible only in errno, and errno is gone by the time a Mere program can ask. Every call stores its own errno (0 on success) in a per-thread slot, and proc_last_errno reads it.

scripts/proclimit_check.sh, 55 rows, in CI: limits set and read back, a nice value raised and read, a lock taken through one open and refused through another, and the refusals (unknown name, soft above hard, bad selector, no such process, closed fd). Run on macOS arm64 and on Linux arm64 and x86-64, as root and unprivileged. Poisoned six ways -- a refusal answered as -1, the non-blocking bit mistranslated, infinity not mapped coming out, infinity not mapped going in, getpriority's errno dropped, a failed snapshot left readable -- and each moved at least one row. ⚠ The probe's first run broke itself: a "soft above hard" row asked for the current hard limit plus one, NOFILE's hard limit is unlimited on macOS and crosses as -1, and the soft limit became 0 descriptors. Every open after that row failed. The row names both of its numbers now.

Interpreter, LLVM and Wasm are unchanged, as for file_*: the interpreter says it has no mock for the extern, LLVM and Wasm leave it an import.

v0.1.549 — 2026-09-29

_What a suspended coroutine still holds: coro_scan_ints._

A program that keeps its own handles -- integers into tables of its own, as an interpreter written in Mere does -- and collects them itself could not see what a coroutine that stopped in the middle of an expression still held in C variables of its stack: something it had just taken out of a table. mere-ruby lost the object in [q.pop, Fiber.yield] to a collection and crashed when the fiber resumed (2 of 4 shapes). coro_scan_ints c lo hi f hands f every integer in [lo, hi) that coroutine c's stack can reach:

• a suspended coroutine from where it stopped, the running one from the call up

(registers spilled first);

• a word that points into a live block is followed and the 16 words from

there read the same way -- without limit inside the coroutine's own regions, at most three hops into any other block. Only the allocated part of a block counts (a recycled region's block still holds what was there before), and a word inside no live block is never read through. That takes a list of every live block, which the region runtime now keeps (one per thread; the shared default region's under a lock of its own);

• conservative, never unsafe: it hands over numbers, not values;
• a suspended coroutine's findings are kept until it runs again.

Why a range and not a bound: mere-ruby's handles were small integers, and so were its loop counters and its Ruby Integers. Every one read as some handle, and what those kept kept more -- a dropped Enumerator's fiber came out "reachable" and the reclaim gave back none of 9000. Handles numbered from 2^48 are above every user-space address and every counter; the program asks for that range. (Reading a table's arrays from the middle still reads the neighbouring handles; mere-ruby therefore decides which fibers can run again without the scan, and uses the scan only for what to keep.)

The interpreter and LLVM hand over every integer in the range -- the superset the contract allows. Wasm and RV refuse it by name, with the other coroutine builtins. scripts/coro_check.sh --poison: fixtures scan and scan_high, and poisons for not following pointers, not reading suspended stacks, not reading the running stack, and not following the coroutine's own regions; run on macOS arm64 and Linux arm64. mere-ruby's csv benchmark against v0.1.548's mere-ruby: parse_line 5.03 -> 5.19 s, generate_line 1.26 -> 1.40 s, the rest unchanged.

v0.1.548 — 2026-09-29

_Asking whether a suspended coroutine pins an arena is cheap enough to ask on every recycle._

v0.1.547's question -- does any suspended stack point into this arena? -- rescanned every suspended coroutine's stack each time it was asked, and mere-ruby asks it constantly: it recycles a map at every method return (the frame pool), and CSV.parse_line leaves up to a thousand suspended fibers behind. Its csv benchmark did not finish in an hour. Three changes:

• A coroutine can only point into a block that existed while it ran. Blocks

carry the epoch they were allocated in (bumped by every switch), each coroutine the epoch it last stopped in, and the live list is kept most-recently-stopped first -- so a walk ends at the first coroutine that stopped before every block in question.

• A recycle keeps its region's first block and frees only the growth after

it, so only those blocks are asked about. They are recent, which is what makes the walk above short.

• Each coroutine's candidate words are gathered once per stop -- only the ones

inside the address range this thread's blocks have spanned -- sorted, and binary-searched per block.

The csv benchmark (2000 rows, best of three) against the build before fibers could suspend: parse 1.47 -> 1.44 s, quoted 26.6 -> 26.3 s, headers 1.62 -> 1.52 s, parse_line 4.88 -> 5.09 s, generate_line 1.20 -> 1.40 s. scripts/coro_check.sh --poison still passes, the compaction poison included.

v0.1.547 — 2026-09-29

_Compacting a map or a Vec while a coroutine is suspended is safe (C)._

A coroutine that stops in the middle of an expression can hold a pointer into a store's arena in a C variable of its own stack -- a string it read out of a map, say. map_compact / vec_compact move the store into a fresh arena and free the old one whole, and map_recycle frees its growth in place, so the coroutine resumed into freed memory: held: lost at -O2, a heap-use-after-free under ASan.

Now the runtime asks before it frees. A program that makes coroutines installs a hook (on the first coro_new) that scans every suspended coroutine's stack -- from the stack pointer its switch saved, which covers the registers the switch pushed, to the stack's top -- for a word that falls inside one of the arena's blocks (low three bits masked, for tagged values). If one does, the arena is retired instead of freed, and tried again at the next retirement; a recycle moves the map to a fresh arena and retires the old. The scan is conservative: a word that only looks like a pointer keeps an arena a little longer, never frees one early. A program without coroutines frees at once, as before.

test/coro/compact.mere holds a string across a compaction and a churn that reuses the freed memory; scripts/coro_check.sh runs it on the interpreter and on C, and its new poison takes the retirement out and goes red. (The LLVM backend has no map_compact / vec_compact at all -- it refuses them by name -- so there is nothing there to retire.) Run on macOS arm64, Linux arm64 and x86-64 Linux.

This is what mere-ruby needs to compact while fibers are suspended -- until now it skipped compaction then, and got back entries but not bytes.

v0.1.546 — 2026-09-29

_A free-result function used at two types, and with its result thrown away, no longer calls an instance nobody emitted (C and Wasm)._

let boom = fn (msg: str) -> fail ("boom: " ++ msg);
let as_str = fn (b: bool) -> if b then "fine" else boom "str";
let as_bool = fn (b: bool) -> if b then true else boom "bool";
let thrown = fn (u: unit) -> let _ = boom "thrown" in 0;

boom's result type is free (it ends in fail), so it is instantiated once per type it is used at: str -> str and str -> bool. The call in thrown throws the result away, its type stays a variable, and the backend names that call's instance with the variable erased to int -- mu_boom__str__int on C, $boom__str__int on Wasm. Nothing emitted it. The compiler said nothing; clang said "call to undeclared function" and wat2wasm "undefined function variable". The monomorphizer already recovered the same hole for a function that never concretized at all (it emits the erased instance for a call site that names one); a function that did concretize, at more than one type, fell outside that. It is covered now, in the same fixpoint: a recovered body may call a function the other recovery has to supply.

The C and Wasm backends name a residual call that way and now get the instance; LLVM refuses such a program by name, as it did. Two further holes showed on Wasm, both found by the self-hosted codegen's bootstrap test: a recovered instance's body calls other polymorphic functions at types the main pass never saw (the fixpoint now collects those too), and a backend lists a name's specializations from the instance table, which the recovered ones were missing from.

Found by mere-ruby's scheduler, whose delivery of a pending exception used re_raise for its value where a dozen other sites discard it. test/parity/free_result_thrown_away was red before and is green after.

v0.1.545 — 2026-09-28

_A finished coroutine keeps 24 bytes, not its saved state._

A Coro is a value the program may go on holding after the coroutine has finished, and switching to it must then fail by name, so the record a handle points at is never freed. It held everything: the saved registers' jump buffer, the parked runtime state, the stack's bounds. A million coroutines made and dropped held 339 MiB on C and 522 MiB on LLVM after they had all finished.

The record is two now. The small one -- state, owner, and a pointer to the rest -- is what the handle points at and what the checks read. The large one is freed when the coroutine is reaped, along with its stack going back to the pool. The same million hold 34 MiB on both backends.

scripts/coro_check.sh bounds that program's resident memory at 128 MiB on C and LLVM, and a poison per backend takes the free back out; both go red. The measurement is /usr/bin/time (BSD -l or GNU -v); where there is neither, the check fails and says the question was not asked, rather than passing. Run on macOS arm64, Linux arm64 and x86-64 Linux (emulated, with C and IR emitted ahead).

mere-ruby's Fibers moved onto the coroutines the same day, and that is where a million of them is an ordinary program: one Enumerator stepped per CSV line.

v0.1.544 — 2026-09-28

_LLVM lowers the coroutines too, without assembly._

The C runtime switches stacks with a few lines of assembly per target. The LLVM backend's output is IR that is not specific to one machine -- its runtime decides the platform at run time, off one icmp -- so it cannot carry a register swap for arm64 and another for x86-64. It does not need to. Between two stacks that already exist, a switch is _setjmp on the way out and _longjmp on the way in; the one step that has to set the stack pointer, entering a coroutine for the first time, is llvm.stackrestore onto the top of its stack followed by a call. Measured the same as C: two million switches in 0.11 s at -O2. Checked at -O0 through -O3 on macOS arm64, Linux arm64 and x86-64 Linux, and with _FORTIFY_SOURCE.

What a switch carries is C's four pieces plus this backend's ListBuf depth word. The guard page is posix_memalign + mprotect rather than mmap, because the MAP_* flags differ between Darwin and glibc and the protections do not. The thread's own record is on the heap, made on first use: a large thread-local lands in each thread's stack on glibc (v0.1.541).

One refusal C does not have: a coroutine made while a region block is current fails by name. This backend's closures carry no env copier, so the body's env would be released with the block; C copies it out.

Found on the way: a region block whose result is a Coro asked the variant tables about it, as if every named type were a user variant, and the backend stopped with unknown variant type.

Both runtimes now keep finished stacks for reuse, up to 16 per thread, linked through a word at the bottom of each: making and finishing 100,000 coroutines on C went from 1.10 s (0.64 s of it in mmap / munmap) to 0.02 s of user time. And the guard below each stack is 64 KiB instead of one page, because clang does not probe a large frame on Linux and a frame bigger than the guard steps over it. That also answered v0.1.543's open note: under x86-64 emulation on an arm64 Mac the overflow at -O2 died unnamed with a one-page guard, and is named with this one. The emulator runs on 16 KiB host pages and a 4 KiB guard is a quarter of one. Real x86-64 (CI) named it either way. There is no poison for the guard's size: a frame between one page and 64 KiB is not something a Mere program can be made to have on purpose.

scripts/coro_check.sh now runs every fixture on LLVM at -O0 and -O2 as well, with seven poisons on the emitted IR beside the seven on the emitted C; each turns its fixture red. test/coro/pingpong became 1000 x 1000 switches: as a single recursion a million deep it measured the stack at -O0 rather than the switch. Run on macOS arm64, Linux arm64 and, with C and IR emitted ahead, x86-64 Linux under emulation: every fixture and every poison as expected.

v0.1.543 — 2026-09-28

_Same-thread coroutines: coro_new, coro_switch, coro_self (interpreter and C)._

Until now the only way to leave a stack standing and come back to it later was spawn: one OS thread per suspended computation, a switch that is a channel round trip between two threads, and a thread's creation cost per suspension. A coroutine is a second stack on the same thread. coro_new : (unit -> Coro) -> Coro makes one without running it; coro_switch : Coro -> unit hands the thread to it; coro_self : unit -> Coro names the one running. The body's result is the coroutine to hand over to when it ends, because transfer is symmetric and there is no parent to return to.

Swapping registers is the easy part (a few lines of assembly per target, arm64 and x86-64). What a switch must also carry is every piece of runtime state that belongs to a stack rather than a thread. On C there are four: the current region, the stack of open blocks a fail unwinds, the innermost try_or's jump buffer, and the stack bounds the SIGSEGV handler compares a fault against. Leave any one on the thread and the program reads freed memory, releases another stack's blocks, jumps onto a stack that is not running, or reports its own overflow as a segfault. The interpreter carries its three (call depth, the call stack a failure prints, the current region's id) and builds symmetric transfer from OCaml 5's asymmetric effects: only a thread's root runs a driver, and a coroutine that switches returns its continuation to it. A fail no try_or on the coroutine's own stack catches is uncaught on both, rather than landing in a handler the switching stack had open.

Coro is neither Send nor Sync. A body whose captures include a container made inside an open region R { } is a type error: the body's env is copied into the default region when the coroutine is made, which is right for a value and wrong for a handle. Switching to a finished coroutine fails with a message, as does a body that ends by naming itself. On C a coroutine's stack is the size stack in mere.toml asks for, or 8 MiB, reserved below a guard page, and its overflow is named. LLVM does not lower these yet; Wasm and RV refuse them by name, with the reason.

Found on the way: fail and exit in a position that wants a Vec, Map, Channel or Coro emitted (Vec___rp12_int){0} after the noreturn call -- a struct nobody declared -- and clang refused the program. The three sites that make that unreachable value (with the match fallthrough, which had the pointer case since v0.1.51) now share one function. test/parity/fail_pointer_result was red before and is green after.

scripts/coro_check.sh (CI, with a poison): eleven fixtures in test/coro/ on the interpreter and on C at -O0 and -O2, the refusals, and one allowed capture. The poison edits the emitted C to drop each of the four carried pieces, the env copy, and the two runtime checks, and the fixture that exists for each must go red; all seven do. Run on macOS arm64 and Linux arm64 (ubuntu 24.04, clang 18). On x86-64 Linux under emulation the fixtures and poisons are green except the overflow at -O2, which dies unnamed; the same emulator also loses the name for a plain main-thread overflow at -O1 about half the time while a hand-written C program with the same handler never does. Real x86-64 is CI's to answer.

v0.1.542 — 2026-09-28

_LLVM: two threads can allocate at once (Q-180)._

The LLVM backend's allocator took no lock on the default region, which every thread shares (the C backend's does), and its current region and stack of open blocks were process globals (C's are thread-local). Two spawned threads building strings at the same time -- sharing nothing -- died with out of memory in 3 runs of 3; doing it inside region R { } blocks, they hung or crashed. One thread alone was fine, which is why nothing saw it: no gate ran two allocating threads concurrently on LLVM.

The default region now takes a one-word spin lock (cmpxchg: a zeroed pthread_mutex_t is not an initialized one on macOS), taken only for the default region; a block region belongs to the thread that opened it. The current region, the open-block stack and the ListBuf depth word are thread-local -- small words only, since a large thread-local lands inside each thread's stack on glibc (v0.1.541). The allocation meter adds atomically.

scripts/threads_alloc_check.sh (CI, with a poison): two threads allocating at once, in the default region and inside block regions, three runs each on C and LLVM under a time bound. The poison takes the fix back out of the emitted IR -- the lock calls, then thread_local on the current region -- and each must turn a fixture red. Run on Linux (ubuntu 24.04, clang 18) and macOS.

v0.1.541 — 2026-09-28

_LLVM: a spawned thread's alternate signal stack is its own block, not a thread-local one._

v0.1.540 made LLVM's 128 KiB alternate signal stack thread_local so that every thread could name its own overflow. On glibc, static TLS lives INSIDE each thread's stack, so a thread created with a small requested stack had no room for it and pthread_create refused: stack = "128K" made every LLVM program on Linux fail with "this host refused the stack this program asked for". macOS allocates TLS apart from the stack, which is why it passed there, and spawn_stack_check.sh's poison caught it on CI's Linux. The buffer is a plain global again, used by the main thread; a spawned thread mallocs a block of its own, installs it, and disables and frees it when it ends (the C backend has done it that way since v0.1.540). Checked on Linux (ubuntu 24.04, clang 18.1.3) and macOS: spawn_stack_check and stack_request_check with their poisons, thread_fail_check, thread_leak_check.

v0.1.540 — 2026-09-28

_A spawned thread gets the stack the program asked for, and its overflow and its fail stay its own._

`spawn` honours `stack` (Q-178). Q-168 let a program say stack = "512MB" in mere.toml, and the C and LLVM backends run main's work on a thread of that size. spawn called pthread_create with no attributes, so every thread a program started had the host's default -- 512 KiB on macOS, ulimit -s on Linux -- whatever it had asked for: the recursion main finishes overflowed one spawn away. With a request, both backends now create every spawned thread with the same size; without one the emitted code is unchanged. The request is still address space and not memory: 64 threads under a 512 MB request hold about 2.6 MiB resident.

A spawned thread's overflow is named. The bounds the SIGSEGV handler compares against were process globals holding the main thread's stack, and sigaltstack -- which is per thread -- was installed on the main thread only. A spawned thread that ran out of stack therefore died with the handler unable to run: no output, exit 132 or 139, the shape v0.1.271 removed everywhere else. The bounds are thread-local now, and a spawned thread sets its own bounds and alternate stack on entry (C: a 64 KiB block allocated for the thread and released when it ends; LLVM: the existing buffer, now thread-local).

LLVM: a fail on a spawned thread no longer lands in another thread's `try_or`. The C backend has had one jmpbuf per thread since v0.1.310; LLVM still had one global, so a fail on a spawned thread with no try_or of its own jumped into the one main was sitting in -- onto another thread's stack -- and main carried on with the handler's value as though it had failed itself. It is thread-local now, and the fail takes the thread's uncaught path (the message, exit 1), as on C. Found while writing the gate below.

A thread that cannot be started is a fail. pthread_create's return code was ignored on both backends, so a refused thread left its handle unset, the closure never ran, and the program went on to join it. It is a fail now ("spawn: the host refused to start a thread"), catchable with try_or like any other; so is a stack size the host refuses.

scripts/spawn_stack_check.sh (CI, with a poison): deep recursion inside spawn finishes with the request and is named as a stack overflow without it, on both native backends; a spawned thread's fail takes its own uncaught path; 64 threads under a 512 MB request stay small. The poison asks for 128K and requires the spawned recursion to stop -- a request that was not reaching spawn would pass everything else on a host whose default is large.

v0.1.539 — 2026-09-28

_The second lexer catches up with the first, and the file's last line keeps its comment._

The self-hosted lexer read ten operators wrong (Q-153). contrib/parser/lexer.mere split |> -- the language's own pipe -- into Pipe and Gt, split <|, <<, >>, <> and <- the same way, and failed outright on @@, ?!, ? and &. selfhost_check.sh stayed green throughout, because the bootstrap corpus uses none of them. All ten are tokens now. The self-hosted parser does not read most of them yet, which is why adding them breaks nothing; what it needed first was the text split where the compiler splits it.

scripts/selfhost_lexer_ops_check.sh (CI, with a poison) does not list the operators: it derives them from lib/lexer.ml's arms -- every 'c' when ... s.[i + 1] = 'd' is a two-character operator, every 'c' -> advance 1 a one-character one, 40 in all -- and requires each to be one token in the self-hosted lexer. Against the old lexer it names the ten. // is left out on purpose (it begins a comment in both), and the backslash arm, the one written as two characters in the OCaml source, is asked for by name after the first version of the gate missed it. Reserved words are a separate gap and are not asked: the self-hosted parser reads import as an identifier, so the lexer cannot make it a keyword alone.

`mere fmt` keeps the comment on the line a file ends with (Q-154, slice 6). sum xs // 15, the shape an example file ends in, lost its comment whenever the expression was the tail of a run of let ... in: the formatter only puts a trailing comment back where it emits the whole line, and never asked at the end of a let run -- correctly, in general, because a caller may append the ; or ) that closes the run, and a comment placed before it swallows it. The one tail nothing is ever written after is the expression the whole file ends in, so that one is recognised by identity and asked. Comments lost on the examples corpus: 99 -> 93. What is left, by the line it was on: an if / then inside an expression 30, a line ending in the caller's ; 26, a variant or match arm 12, let ... in 7, , 6, else 5, other 4 -- plus 7 that are // inside a string literal and not comments.

v0.1.538 — 2026-09-27

_Four known failures, each of which had a written record and none of which had been fixed._

`f_min` / `f_max` with a NaN or a signed zero (Q-177). The interpreter answers with OCaml's Float.min / Float.max and Wasm with f64.min / f64.max; C and LLVM compiled a < b ? a : b, which is not symmetric in a NaN -- false with the NaN first, so f_min nan 1.0 was 1.0 while f_min 1.0 nan was NaN -- and returned equal zeros in argument order, where -0 is below +0. The RV32/RV64 prelude had copied the C spelling on purpose. All three now transcribe OCaml's stdlib step for step:

c   = y > x || (!signbit y && signbit x)
min = c ? (isnan y ? y : x) : (isnan x ? x : y)
max = c ? (isnan x ? x : y) : (isnan y ? y : x)

The first version used a + b for the NaN case, and rv_float_check.sh caught it: a signalling NaN comes back from OCaml as it went in, and an add quiets it -- same NaN, different bits, and that gate compares bits. The transcription returns the operand itself. test/parity/float_minmax.mere covers every pair of eight values on the parity backends, and test/float/rv_float_ops.mere now asks f_min / f_max of every pair on RV32I, bit for bit against the machine (3440 lines).

`run` reported a shell killed by a signal in OCaml's numbering (Q-088). v0.1.360 wrapped the command in a subshell so the shell run waits on usually survives to report 128 + signal itself. When the shell itself is the one killed -- kill -9 $$, since $$ is that shell even inside the subshell -- the interpreter read the status from waitpid, which carries OCaml's encoding (Sys.sigkill = -7), and answered 121 where the C backend answered 137; 117 for SIGTERM, 116 for SIGUSR1. OCaml's named signals are now translated to the system's numbers: 1-15 other than SIGBUS are the same on Linux and macOS, and the rest are chosen by the system the compiler was built for, which dune writes into Platform_config from %{ocaml-config:system}. Three rows in run_status_check.sh kill the waited-on shell; with the translation removed they fail as 121 / 117 / 116.

`mere -t` accepted programs the build refuses (Q-083). The type query runs no borrow, move, Send or exhaustiveness check, so a non-exhaustive match typed there and was refused by mere -c -- and a measurement once made with -t concluded that a check did not exist. -t and -te still exit 0 with the type, which is what editors and scripts asking a type question need, and now print the build's own diagnostic on stderr under "note: mere -t answers a type; it does not accept the program". The findings come from Pipeline.type_notes, which runs the build's checks and puts back the warnings they collect, so -t prints nothing new for a program the build accepts.

`view` was reserved and nothing said so (Q-084). let view = 5 failed with "expected pattern", and view was in neither docs/reserved-names.md nor language-reference.md's Keywords block -- which was also missing trait, impl, dyn and derive. The lexer's reserved words are a table now (Lexer.keywords); the parser names one when it is used as a name ("view is a reserved word, so it cannot be a name here"), and scripts/keywords_doc_check.sh (CI, with a poison) requires every word in the table to be listed in both documents.

And a warning that was false on every backend. Writing that section turned up the other half of reserved-names.md: "a top-level name that collides with a C keyword or libc/libm symbol ... will be a compile error at codegen". It had stopped being true -- every backend prefixes a top-level binding (mu_div on C) -- and a program binding div, malloc, printf, memcpy, strlen, case and main printed the same answer on the interpreter, C, LLVM, Wasm and RV32. The warning is gone. TYPE names are not prefixed on the C backend and do still collide (type wait against union wait), so that warning stays, and reserved-names.md and patterns.md say which is which.

dune test 2868/0, parity 188.

v0.1.537 — 2026-09-27

_utf8_chars split a stray continuation byte onto the character before it, on all three compiled backends._ test/parity/prop_utf8.mere had pinned the disagreement since contrib/prop found it: for "A" ++ chr 128 the interpreter gives two characters and C, LLVM and Wasm gave one, so codepoint_at s 0 was 65 on one and a refusal on the others. The file's own note said the difference had to be under the prelude, because the span logic is one Mere source compiled by all four.

It was the builtin. Each compiled backend implemented utf8_chars as a BACKWARD walk -- start at the end, step back over continuation bytes, take what is left as one character -- which gives every continuation byte to whatever precedes it, a lead byte or not. The interpreter splits FORWARD by the lead byte's span, and so did the compiled backends' own utf8_len, which is why the two builtins disagreed with each other inside one backend. No backward walk can reproduce the forward rule: a lead byte does not check what follows it (0xE0 'A' 'B' is one three-byte span), so the boundaries are only known from the front. All three now record the starts going forward (C: malloc; LLVM: malloc, because a string can be megabytes; Wasm: the bump region) and build the list from the back, as before.

The three .expected pins are deleted; prop_utf8 is MATCH on all four.

v0.1.536 — 2026-09-27

_A cached test prints nothing._ With dune on the PATH (v0.1.535), first_run_check got one step further on CI and failed on the next thing: dune test printed no "N passed" line . Its own comment explained why, as a feature -- "dune caches it, so on an unchanged tree this costs nothing" -- and a cached test action is not re-run, so it prints nothing, so there is no count to read. CI runs dune runtest a few steps earlier, so on CI the tree was always unchanged and the check could never pass there; locally it passed whenever something had just been rebuilt, which during a change is always. Reproduced by running it twice in a row, which fails on the second. It asks dune test --force test now: the suite the count comes from, re-run, about four minutes.

v0.1.535 — 2026-09-27

_CI had been red since v0.1.531, on two steps that were right about something and wrong about where._ The Gates job failed on tool_preflight and first_run_check for every push from v0.1.531 to v0.1.534, while every gate passed locally -- including those two, which is how four versions went out on a red build. ⚠ The local sweep in v0.1.533 ("run every gate") was run on a laptop, and the laptop is not the runner.

`first_run_check`: the one real finding. v0.1.533 derives the README's test count by running dune test, and the CI step ran the script without opam exec --, where dune is not on the PATH: FAIL first_run[counts]: no dune. The step runs under opam exec -- now. tool_preflight had said so -- dune — scripts/first_run_check.sh would skip -- in the same log, under four false alarms.

`tool_preflight`: four false alarms, three causes.

• initdb and pg_ctl: the PostgreSQL install step sat between two gates,

well after the preflight, so the tools were not on the PATH yet when the preflight looked. The gates that use them ran and passed. The install is with the other tools now, before the preflight.

• riscv64-elf-objdump: the preflight resolves command -v "$OBJDUMP" from

the script's default, the Homebrew name, while CI runs the gate as OBJDUMP=riscv64-linux-gnu-objdump sh scripts/rvd_oracle_check.sh. On CI (GITHUB_ACTIONS set) the name CI passes the gate is the one asked about; off CI the default still is, because that is how a developer runs it. A sixth poison replaces CI's name with one that does not exist and requires the preflight to report it.

• brew: tls_server_check.sh asks Homebrew where OpenSSL's headers are on

macOS; on Linux they are on the default path and the gate runs 19 checks without it. It is in ALLOWED_ABSENT, with that reason.

The preflight step runs under opam exec -- too, so that dune -- a tool a gate CI runs needs -- is asked about in the environment that gate gets.

`fma_check`, new in v0.1.534, was red on its first CI run. Its LLVM leg compiled the .ll with $CC, which on the Ubuntu runner is gcc, and gcc took the IR for a linker script. The LLVM leg uses clang now (LLVM_CC); the C leg keeps $CC, so the runner checks gcc's answer there as a second compiler. ⚠ A new gate is supposed to run once on a CI-like Linux image before it is pushed; this one was not, and its first Linux run was the CI run. It has been since: x86-64 Ubuntu (gcc 13 at -O0 and -O2, clang 18 for the IR, glibc's fma as the oracle) and arm64 Ubuntu under dash, all six families matching. A leg that prints no checksums at all is now reported with what it did print -- under node 18, which has no tail calls, the report had been "differs in:" and an empty list.

v0.1.534 — 2026-09-27

_fma: one rounding, asked for by name — and two LLVM bugs its gate found on the way._

`fma a b c` and `f64x2_fma` compute a * b + c rounded once (Q-176). a * b + c written out is unchanged: it rounds twice, on every backend at every optimization level, which is what the C backend's #pragma STDC FP_CONTRACT OFF has guaranteed since v0.1.315. Fusing is now something a program asks for, and what it gets is a different answer that is the same everywhere: fma is one of the operations IEEE-754 requires to be correctly rounded, like + - * / and sqrt.

Why it is worth a builtin, measured on mat4xvec4 through the C backend: the f64x2 kernel written with f64x2_fma runs in 100 ms against 140 ms for f64x2_mul + f64x2_add, and clang turns each pair of lane fmas into one fmla.2d. It is not the benchmark row, because that row's claim is that the scalar and lane programs print the same bytes.

Lowering: the interpreter uses Float.fma, C calls fma(3) (per lane for f64x2_fma), LLVM calls llvm.fma.f64 / llvm.fma.v2f64. Wasm has no fma instruction and the host's `Math` has none either, so $__lang_fma computes it in the module, in integers: the three significands normalized to 54 bits with bit 0 clear, the 108-bit product built from 32-bit halves (Wasm has no 64x64->128 multiply), c aligned against it with a sticky bit for whatever is shifted out, one add or subtract, and ONE rounding -- the conversion of the top 63 bits to f64, pre-rounded at the subnormal's last place when the result will be subnormal so the final scaling does not round again. The structure is musl's. About 12 ns a call on node 24, four times the unfused arithmetic. The alternative was to refuse fma on Wasm, and a program would then write a * b + c for that one backend and get a different answer there -- the thing the pragma exists to prevent. The RISC-V backends refuse the name: they have no double-precision unit, and the 90-bit working width of the software floats there has no room for a 106-bit product.

`scripts/fma_check.sh` (CI) holds all four backends to the C library's fma(3), bit for bit, on six families of inputs: all 10,648 triples of 22 special values, fully random bit patterns, products at the edges of the exponent range, exact and near cancellation, and ties decided by a single sticky bit. The last family exists because random inputs essentially never land on a tie: while the software fma was being written, dropping the sticky bit of a shifted-out c passed 20 million random cases and failed 10,272 of 20 million once ties were in. The gate's own poison is fma redefined as a * b + c, which must not match (it differs in 6 of 6 families). Before it was transliterated, the algorithm ran 250 million cases against the hardware fma natively and the WAT ran 50 million under node, all bit-identical; two of its sticky paths (the product shifted right, or out entirely, against a much larger c) could not be made to change an answer and are argued unobservable rather than tested -- a 53-bit by 53-bit product cannot have 64 zero bits between two set ones.

LLVM: `x != x` said a NaN was not a NaN. Float != was the ordered fcmp one, which is false when either side is a NaN; the interpreter, C and Wasm give IEEE-754's answer, true. It is une now. Found because the fma gate folds NaN results with exactly that test, and the LLVM leg alone disagreed -- on the one family that produces NaNs. test/parity/float_edges.mere asked ==, < and > of a NaN and never !=; it asks all six now, and fails with the old predicate.

LLVM: a local binding of a builtin's name leaked into `main`. main was emitted with the inner-lift view of whichever fn had been emitted last, so a let atan2 = ... inside a fn made every atan2 in main call that local: atan2 1.0 1.0 printed 2.0. main's own local fns are not lifted through that table at all, so its view is the empty one now. Found by the fma parity case, which binds a local fma and uses the builtin elsewhere in the file. ⚠ Only the LAST host's lifts leaked, so the first version of test/parity/local_shadows_builtin.mere passed with the bug in place -- a later fn with its own lifted local had replaced the table. The fn that shadows is the last one in the file now, and the file fails without the fix.

Also found and left for its own version: f_min / f_max with a NaN argument return NaN on the interpreter and Wasm and the other operand on C and LLVM, depending on argument order.

dune test 2862/0, parity 187 (fma, local_shadows_builtin).

v0.1.533 — 2026-09-24

_Running every gate, rather than the ones that looked affected._ A full local sweep of the 124 gates CI names found three red, and two of them had been red on main.

`section_coverage` — mine, from v0.1.528. wasm_stdin_host_used is a gated runtime section, and a gated section with no row in test/parity/SECTIONS is text that is emitted by nothing and therefore validated by nothing. I added the flag and not the row. test/parity/read_stdin_host.mere is that row. ⚠ Its calls are emitted and not executed, on purpose: the harness gives a program no stdin and does not close it, so a real read_line () blocks until the timeout — the first version of the fixture did exactly that. The guard is args (), empty here and unknowable at compile time. section_coverage checks that a section is EMITTED; wasm_stub_check.sh is the gate that feeds it real bytes.

`trailing_trim_check` — red since v0.1.510. fail_reason_check.sh uses sed '$d', which the gate forbids outside an allowlist. The use is legitimate and the same shape as parity.sh's: on the plain Wasm host the diagnostic goes to stdout when stderr is empty, so the last line IS the message and both halves are then compared. It is on the allowlist now, with that reason.

`first_run_check` — the README's own sentence came true. It said the parity count is re-derived "because a number in a README rots silently — and the test count is not ... and nothing checks it". The parity count had drifted 180 → 185 and the test count 2796 → 2856. Both are derived now: the test count by running dune test and reading its own "N passed" line, which is what the number is about. A sentence that names its own failure mode is not a check.

⚠ Nothing found today was found by the build. Two of these were red on main while four versions were pushed, because each push ran the gates that looked related. The sweep is the thing that had not happened.

dune test 2856/0, parity 185+30.

v0.1.532 — 2026-09-24

_A gate in no workflow has never had to pass._ v0.1.531 asked whether a gate CI runs could skip. This is the other half: three gates were in no workflow at all, and one of them was red.

rv_exec_check.sh is the differential between the RISC-V backend and the C backend on the hosted side — the half qemu_virt.sh does not cover, and one of the three boundary checks a conference talk cites. Nothing ran it. Run on 2026-09-24 it exited 1: int_width_boundary, added to the parity suite for a different question (Q-039 pins where the interpreter's 63-bit int and the compiled backends' 64-bit one part company), differs by construction on a 32-bit target — bit_shl 1 60 is 1152921504606846976 on the C backend and 0 there. It is in KNOWN_DIFF now with that reason, which is what the list is for: a name in it that stops differing also fails.

64 bits: 105 passed, 0 failed, 2 known-different. 32 bits: 98 passed, 0 failed, 4 known-different. ⚠ 84 programs are refused by `-rv` at compile time and do not run, so "98 agree" has a denominator of 186, not 98 — host_matrix.md holds the reasons.

tool_preflight_check.sh grew the second question: every `scripts/*_check.sh` must be named in a workflow, or listed with the reason it is not. 90 gates, 0 unwired. The two exceptions are named: rv_float_check.sh needs an emulator checkout and minutes of emulator time, and bigstr_check.sh allocates gigabytes by design and no runner can host it. Two more poisons (a gate falling out of every workflow; the gate glob collapsing), five in total.

⚠ Found by re-measuring numbers for a talk, not by the build. The build had nothing to say, because the check was not in it.

dune test 2856/0.

v0.1.531 — 2026-09-24

_A gate that did not run is not a gate that passed._ 65 of this repo's gates exit 0 when a tool they need is absent, and 46 of them are named in `ci.yml`. Both halves of that are reasonable on their own — nobody should need psql to work on the parser, and a build should not go red because a laptop lacks wat2wasm — and together they mean this: the day a package is renamed, the best-effort install fails, the gate skips, and CI is green with the check gone.

qemu_virt.sh is the case that matters. It is the differential against an emulator nobody here wrote, which makes it the strongest oracle in the repo, and it was installed with continue-on-error: true and skipped cleanly when absent.

scripts/tool_preflight_check.sh fails in CI, before any gate runs, naming the gate that would have disappeared. The tool list is derived, not typed: every command -v in scripts/*.sh, mapped back to the gate that probes for it, and a tool counts as required when a gate that probes for it is named in ci.yml. 33 tools across 93 gates; 31 required.

⚠ The first version missed the gate it was written for. qemu_virt.sh probes command -v "$QEMU", and a scan that reads only literal names sees a variable and moves on — so qemu-system-riscv32, the whole argument, was not in the list. $CC (39 sites) and the loop variables went the same way. There are four shapes, and the derivation resolves all four: a literal, a variable with a VAR=${VAR:-tool} default, a for t in clang wat2wasm node loop, and a have() { command -v "$1"; } helper.

⚠ And it printed "0 of them are needed by a gate CI runs" and called itself ok. The derivation had silently produced nothing — which is the failure this file exists to describe, written into the file about it. There is a floor now, and its poison is one of three: the tool this was built for going missing, the gate-to-CI link breaking, and the floor being a real number. Each asserts the message it should print rather than a non-zero exit.

⚠ A shape-based scan gets false positives for free. The prose "have to" in a comment parsed as a tool named to. Comments are stripped first, and the one genuine false positive left — command -v mere, which three gates use to find the compiler and which they fail loudly without — is named in ALLOWED_ABSENT with its reason rather than quietly dropped.

dune test 2856/0.

v0.1.530 — 2026-09-24

_Rename handed back a program that does not compile._ Top_let's binder is a pattern and has carried a position since the beginning. Top_let_rec's was a bare string, so everything that had to point AT the name pointed at the VALUE instead — a different line as soon as the fn is written under the =, which is how most of mere-ruby's ~2,500 top-level functions are written.

Three things were wrong, and the third is the one that touches files:

Top_let_rec was not in the match that says "a top-level declaration's own name is an occurrence too", so a rename rewrote every use and left the definition alone. The local let rec ... in had the same hole.

Top_let_rec and Let_rec now carry (name, its own position, value). That is 76 sites across 15 files, and the point of doing it as a widening rather than a side table is that fst, snd and List.assoc stop type-checking the moment a pair becomes a triple: the compiler named every place that had to decide, including four in the backends and two in the REPL. A pass that SYNTHESISES a binding — while desugaring, the RV fast-path clone, monomorph's copies — has no name in the source and passes the value's loc, which is exactly what every binder got before.

⚠ The automated part of the edit widened three tuples that were not rec binders (a (name, ty) list, a (expr, params) list, and eval's placeholder refs). Each one type-checked as a different error a step later and had to be put back. Mechanical is not the same as safe; the type checker caught all three, which is the argument for the widening.

scripts/lsp_binding_position_check.sh drives the real server over JSON-RPC and asks the same two questions of five binding forms. ⚠ Every fixture puts the value on the line AFTER the binder, because a one-line fixture cannot tell the two positions apart — and the gate asserts that about itself before it trusts any of its own rows. On the previous compiler it reports six failures naming fn as the definition; on this one, none. Five unit tests cover Query directly and three of them go red without the fix.

A stale exemption went with it. decls_roundtrip.sh carried one program that could not round-trip, with the rule "if it starts passing, FAIL, because the exemption has outlived its reason". Q-125 fixed the underlying gap in v0.1.525 and the rule fired the first time anyone ran the script afterwards. 172 programs, no exemptions.

dune test 2856/0, parity 184+30.

v0.1.529 — 2026-09-24

_Only the editor was red._ mere -t resolved import "dep.mere" against the current working directory. Every other path that reads a file — -c, -ll, -w, check, fmt, fix, --decls, --header, --suggest-regions, --dump-region-params — resolves it against the file's directory, which is where the file's author wrote it. So a program the build accepts was rejected by the type query, with cannot resolve path (tried: /dep.mere) naming a path nobody wrote.

The tool most likely to be on this path is an editor, and an editor is the thing least likely to share a working directory with the file it is showing.

One line: -t passes ~base_dir:(Filename.dirname path) like its twelve siblings. The other four handlers that looked like they were missing it were measured and were not — they compute it a few lines further down.

scripts/type_query_imports_check.sh asks five paths the same question from a directory that is not the file's, and is poisoned twice: the fixture has to actually depend on its import (otherwise a compiler that never reads import passes every row), and a genuinely missing import has to be refused with a message that says where it looked. It reports -t as the only failure on the compiler from ten minutes ago.

This is NOT the other half of Q-083 — -t skipping the borrow and capture checks is deliberate, documented in mere --help, and unchanged.

dune test 2851/0, parity 184+30.

v0.1.528 — 2026-09-24

_The two builtins the gate could not see were the two that were broken._ read_stdin and read_line answered the empty string on plain Wasm, under a comment saying a browser host has no stdin. True of a browser. False of scripts/run_wasm.js, which has an fd 0 — and false of docs/host-matrix.md, which called both yes. This is the rest of the job v0.1.350 did for run, env_var and file_exists, and it was left undone for the same reason it was invisible.

An empty string is what EOF looks like, so the program did not fail. It read nothing and carried on.

Both now go through the host. scripts/mere_host.js grows the one stdin reader every Node host shares — it has to be one, because the buffer is: two independent read_lines would each hold half of a line. Checked against the interpreter and the C backend on four inputs, multi-byte included: three lines consumed in order, a short read at EOF, empty input, and ま/る split across a chunk boundary by construction. A host with no stdin answers 0, which becomes a real empty str rather than a null pointer, because a caller reading the length header of 0 reads whatever is at address -4.

The exclusion list is where the bug lived. scripts/wasm_stub_check.sh said so in a comment:

# read_line / read_stdin / file_openrw are left out: their answers # depend on stdin or on writing a file, neither of which is fixed # across a run.

Stdin is fixed by feeding it and a file is fixed by choosing its path. All three are probed now; the gate went red naming both stubs with their evidence (C=mere_stub_probe_line Wasm=) before the fix and reports 0 after.

A fourth probe was measuring nothing. read_file_bytes was probed with bytes_len, and read_file_bytes answers Vec[R, int], so the expression was a type error and the gate had recorded refused for it since the day it was written — a word that reads like an answer.

The gate now states what it is a fraction of. "10 builtins probed, 0 stubs" says nothing about the eleventh. The Wasm backend's host surface is the set of (import "env" ...) names it can emit, and it is 39. Fourteen probes reach 32 of them; the other 7 are named with the reason nothing probes them — memory is not a function, exit_proc's answer is an exit status that exit_status_check.sh owns, and the five concurrency imports have no answer that is fixed across a run. The list is checked in both directions, so a skip that stops being true fails instead of drifting into fiction. Poisoned four ways, each asserted by the message it should print rather than by a non-zero exit.

Found while adding the flag: three flags from v0.1.350 were never reset. wasm_run_host_used, wasm_env_host_used and wasm_fexists_host_used are per-emission state, and a second module emitted in the same process inherited the first one's host imports — one more name its host has to bind or fail to instantiate. Every JS host in the tree happens to bind all three, which is why nothing noticed. Four unit tests emit a program that reaches for the host, then one that does not, and read the second.

dune test 2851/0, parity 184+30, wasm_stub_check 14 probed / 0 stubs / 39-name surface, --poison 4 caught.

v0.1.527 — 2026-09-24

_Q-120 (b): mere --ffi-header writes the C side's header, so a shim stops copying the layout by hand._

extern fn carries float, record-by-value and bytes on the C and LLVM backends. What it did not carry was any way for the author of the other side to KNOW what those look like — the mu_ field prefix, the field order, and the fact that a boundary int is C's 32-bit int and not long long are all this generator's choices. Shims wrote them out by hand:

typedef struct { double mu_x, mu_y, mu_z; } v3;   /* copied */

⚠ That is an ABI held together by two people agreeing. An extern declaration is a promise, not a check.

mere --ffi-header <file> prints the prototypes and the structs they carry, and only the types the boundary reaches — an internal record does not leak into a file the other side compiles against. Nothing new is computed: the prototype builder was already in the C backend and is now one function both callers share, because writing that mapping twice would be two answers the first time either moved.

⚠ `--header` was already taken, by the other direction — Mere compiled as a shared library, for a C caller. The compiler said so (this match case is unused) rather than the two silently becoming one. Two headers, two guards: MERE_FFI_H stays with the library one, this is MERE_EXTERN_H.

scripts/ffi_header_check.sh builds a shim that includes the header, links it against the emitted C, and checks the answer; regenerating gives the same bytes; reordering the record in the Mere source keeps the shim right. Its poison is the hand-copied struct, now stale, giving 607 where the header gives 418.

⚠ The first version of that poison passed for the wrong reason. The shim computed a dot product, which is the same number however the fields are permuted, so a stale copy still looked right. The weights make the order readable.

Still untested and therefore still unclaimed at the boundary: tuples, variants, and passing a Mere closure as a callback. The header does not name them, because naming them would be making the same unchecked promise this replaces.

2,847 unit tests, parity 214/214.

v0.1.526 — 2026-09-24

_Q-161: the syntax hint's window is the statement now, not the failing line._

v0.1.507 gave syntax errors a help: line that answers a spelling from another language. All 18 catalogue rows answered — but only because the evidence sat on the line the parser stopped at:

def f(n):          def f(n):
  return n           0

The first gets help: \def\ — a function is \let name = fn (x: int) -> body;\. The second was silent: ): reads as a type annotation, so the parser walks on and fails at line 2, and def is a line back.

The window walks back to the nearest ; now, capped at two lines. Both numbers are measured: at a cap of 1 the window is the old line-only one and the new row goes silent; at 2 it answers, all 18 old rows still answer, and every poison still goes red. Wider buys nothing that was asked for.

⚠ The fear this question recorded did not materialise. Q-161 said widening the window widens the false-positive window for var / case / val / mut — words that are real identifiers in these repositories. It does not: bound_names walks the WHOLE token list, so "does this file bind that name?" never depended on the window. That was checked at each width rather than assumed, because the question asked for it to be.

Two poisons were added, and the first one written was weaker than it looked:

• The ; is a wall — a spelling three statements back is not offered as the

explanation. ⚠ But that fixture passes at ANY width, because the ; stops it before the line cap is reached, so it says nothing about the cap.

• So the cap gets its own: run the catalogue with the window one line narrower

and the cross-line row must go red. Without it the number in the source would be decoration.

19 catalogue rows, 5 poisons. 2,847 unit tests, parity 214/214.

v0.1.525 — 2026-09-24

_Q-125: a record declared inside a module could not be named in an annotation — and not only from outside. From inside, either._

module M { type t = { a: int }; let get = fn (v: t) -> v.a; }

⚠ That did not compile, in the module that declared the type. The question was recorded as "cannot be named from OUTSIDE the module", and it was also narrower than recorded: variants were fine all along. M.v worked, v worked, inside and out.

The asymmetry is where the qualification lands. A variant's lands on the CONSTRUCTOR — M.A still builds a v — so the type stays canonical and any annotation matches. A record's landed on the TYPE NAME: the literal became M.t { … } and every annotation resolved to t, so the two could never meet.

A record's identity is its bare name now, the way a variant's already was. The canonicalisation is in the parser, at the two places it builds a qualified record literal or pattern — ⚠ one place rather than the 87 sites that read a record name across the typer, the exhaustiveness checker and both native backends. Putting it in the typer first worked for the typer and left the C backend emitting two structs, M__t and t, for one type.

⚠ Records had no redeclaration check at all, which variants have had since v0.1.474. type t = { a: int }; type t = { b: str }; was accepted in silence and the second won. That was survivable only while M.t and t were different types; making them one would have merged two different records without a word. So the guard lands first, in the same shape as the variant one and with the same kind of message — and the variant wording is not touched, because three unit tests and scripts/doc_claims_check.sh's catalogue pin it verbatim. Restating a record identically is still fine; twelve files here restate 'a list.

scripts/module_type_check.sh asks fifteen questions, and asks the twins side by side: every spelling that must work is asked of a record AND of a variant, because the bug was not "records are broken", it was "records and variants disagree" and nothing compared them.

2,847 unit tests, parity 214/214 with no skips.

v0.1.524 — 2026-09-24

_The same control the Wasm assertions got now covers C and LLVM: 352 substring assertions, every one of them able to fail._

v0.1.523 gave the 97 Wasm assertions a control and found 41 vacuous and eleven FALSE. The same shape was in codegen: (121) and llvm: (138) with no control at all. ⚠ This time there were no lies — measured, not assumed. It is prevention, and it is worth the same as the find: this exact hole kept eleven wrong claims green for a month.

Sixty of the C assertions could not be reached from outside. They are written as let out = codegen "…" in … assert_contains … out …, which no regex over the source can follow — which is why they had never been measured. Moving the check INTO the assertion makes the shape irrelevant: assert_c name out needle does not care how out was produced.

The rule is written once. Three backends print three different things, so what changes between them is how a line says "a function starts here", what ends a body, and how a comment is spelled — not the idea. Unifying the three found two bugs in the version that had been shipping:

• ⚠ "a line at column 0 ends a body" is wrong for LLVM: a basic-block label

sits at column 0 INSIDE a function, so that rule ended every body at its first label and left 5,103 of 5,319 runtime lines in.

• ⚠ A function header starts a body wherever it is written. The Wasm runtime

has one (func nested a level deeper than the other 57; requiring top-level indentation kept its whole body, and with it six assertions went vacuous.

Fifteen C and thirty-nine LLVM assertions take the runtime exemption, and the number is pinned. Two reasons, both written down: the claim is about the runtime rather than about a program ("the idiv helper still uses sdiv", "region_alloc bounds-checks before bumping"), or ⚠ the control uses the same generated name — anon_0_fn is what the first anonymous function is called and the trivial program already has one, so a subject's adapter cannot be told from the control's by name.

scripts/wasm_assert_strength.sh asks all three: a floor on each population, a ceiling on each exemption, and zero assertions left in the unchecked form.

⚠ Not covered, and counted so it is visible: 292 assert_contains remain under prefixes that do not name a backend (vec: 15, owned_vec: 7, of_json: 5, …). Some of them read C output. The prefix cannot be used to sort them, so they are left, and said so.

2,847 unit tests, parity 214/214 with no skips.

v0.1.523 — 2026-09-24

_The Wasm substring assertions now have to be capable of failing, and eleven of them turned out to be false._

test/test_basic.ml checks the Wasm backend by compiling a small program and asserting that some string appears in the emitted module. That is a check only if the string would be ABSENT from a program without the feature, and 41 of the 97 were not: the module carries the whole runtime — 58 $__lang_* functions for the program 0 — so a needle naming an opcode matched whatever was compiled. scripts/wasm_assert_strength.sh has reported that number since v0.1.201.

⚠ The record said none of them were false. Eleven were. Asked about the USER'S code instead of about the module, i32.mul is i64.mul, i32.eq is i64.eq, i32.and is nothing at all, and unreachable and (loop $lp are not in the program's own code either. They are survivors of the i32→i64 widening — the same class as the twenty fixed in v0.1.201, still here because that sweep only asked what was false MODULE-WIDE, and module-wide every one of them was true. A needle that matches the runtime is not merely weak evidence; it can hide a claim that is wrong.

The check moved into the test. assert_wasm compiles the control program 0 once and refuses a needle that also appears in the control's own code, so a vacuous assertion fails the moment it is written rather than being counted by a script somebody has to remember to run. What counts as "the program's own code" is decided BY THE CONTROL — every function the trivial program also defines is boilerplate, $main excepted — because a list of name prefixes has to be maintained, and the first thing such a list got wrong was $show_WCgCol8, generated for the user's own type and named like a runtime helper.

Twelve assertions keep a documented exemption: (module, the exported memory, the imported puts and the like are the skeleton every module has, and asking them to be discriminating would be asking for a lie. That number is pinned, because an exemption nobody counts is how 41 of them got here. Four were deleted as duplicates of a call-site assertion on the same program.

⚠ And the script that measured this reported "0 assertions, 0 vacuous" and exited green once the renaming was done — its denominator had gone to zero. It holds a floor now, and its poison adds an assertion in the old form to a copy of the source to prove the detection works.

93 wasm assertions, 0 vacuous, 0 false. 2,847 unit tests, parity 214/214.

v0.1.522 — 2026-09-24

_Q-052: a local let was writing a top-level binding that happened to share its name, on the LLVM backend, silently. Four lines reproduce it._

let n = 7;
let f = fn (u: int) -> n;
let _ = print_int (codepoint_of "a");
print_int (f 0)

The interpreter, C and Wasm print 7. LLVM printed 1. codepoint_of is the STANDARD LIBRARY's, and it binds its own n inside — nothing had to be imported, no closure trick, no volume of allocation. Any program with a top-level let n that reached it got a wrong answer, which is the failure direction with no symptom.

The backend decided "does this let initialise a file-scope global?" by asking whether the NAME was registered in top_globals_llvm. A name is not a binding. llvm_in_top_level_body now marks the one context where the question makes sense — the top-level let spine of the main body — and every other let is a plain local, whatever it is called.

⚠ The same bug was found and closed on the Wasm backend a month earlier (wasm_in_top_level_body: a local let entries overwrote a KV strbuf pointer and kv_save then wrote 0 bytes). That fix shipped with no gate, and the twin stayed broken. scripts/toplevel_shadow_check.sh asks both backends now, plus the whole corpus for the emit-time footprint: no @mu_* global may be stored from a function other than @main. That was 23 sites across 6 examples before this and is 0 now — and five of those six still printed the right answer, so the behavioural question alone would have called them fine.

Two pinned divergences come off. capture_after_call was Q-052's own case. llvm_loop_guard_global was recorded separately as "a loop whose bound is a top-level binding stops after one iteration on LLVM… whatever n is read from after the lifted thunk has been called is not the global that holds 4" — the same root cause, diagnosed as a loop-guard problem and never connected. Parity's stale-pin detector is what said so.

⚠ Q-052's recorded narrowing was wrong in three places, and all three were written as measurements: it is not the closure's captured value (no closure is needed), it does not need allocation volume (four lines), and the global is not intact (it is the only thing broken — the direct reads that looked fine were using an in-flight value instead of reloading).

2,850 unit tests, parity 214/214 with no skips.

v0.1.521 — 2026-09-23

_mere fmt stops deleting a file's imports and writing somebody else's code into it (Q-174), and the gate that could not see that now asks the question it was missing._

import SPLICES: by the time anything downstream sees a program, the import statement is gone and the imported file's declarations are sitting where it was. For a compiler that is the whole point. mere fmt printed that, so formatting a file DELETED its import lines and copied the imported declarations in — nine imports became zero and seven externs became nineteen on one example — and mere fmt -i saved it over the source.

⚠ Both existing fmt gates were green on it. The inlined output type-checks and is stable on a second pass, so "what fmt writes is still a program" and "formatting twice gives the same file" both pass. They are two spellings of is the output broken; nothing asked whether it is the SAME program. A third question does now: every example with imports keeps every one of them (92 of them), and a fixture pins that the imported file's declaration is not written into the output. Its own poison, because a ceiling poison cannot reach a bug whose symptom is a count going to zero.

The parser records each of the entry file's imports as (index in the declaration list, path as written, how many declarations it spliced, source line), so the formatter undoes the splice exactly rather than guessing from positions — a nested import is already inside its parent's count, and an import that brought nothing in because something else had already pulled that file in is still a line the source wrote, so it still comes back.

Two things followed from it.

extern declarations can be placed now, which recovers the 12 trailing comments v0.1.520 had to leave: placing them used to pick a line from whichever copy of a duplicated name came first, and the duplicate was the imported file's. The ambiguity guard stays, because two externs of one name in ONE file is still something a person can write.

And fmt_comments_check.sh was measuring against a contaminated output. LOST_CEILING went 53 → 111 → 99 in this version and nothing was newly lost: the output used to carry the imported files' declarations, and contrib is full of string literals containing // ("http://", Url._cred), so the subtraction was crediting the output with another file's text. Measured separately, strictly lost comments of the entry file went 151 → 108 over the same corpus and no file lost more of its own. The number is not comparable across this version, and the gate says so where the ceiling is set.

v0.1.520 — 2026-09-23

_A program can say how much stack it needs, mere doc exists, and the gate that was about to certify the next ceiling was not guarding its own denominator._

Q-168: `stack = "512MB"` in mere.toml. Deep recursion has been DIAGNOSED since v0.1.271 -- it says "stack overflow (recursion too deep)" instead of exiting 139 with an empty stderr -- but nothing in the language could ask for more. The answer lived outside the build in three spellings: -Wl,-stack_size on Darwin, ulimit -s on Linux, --stack-size on node. So whoever RAN a program had to know a fact about the PROGRAM.

Translating the request into a link flag could not reach: mere -c emits C and never invokes the linker. But main is a thing this compiler writes, so the C and LLVM backends now put the program's work on a thread sized to the request and join it. Measured both ways on both: two million frames overflow without it and complete with it. A trivial program built with the same request holds 1.5 MiB resident, so it is address space and not memory. Wasm and RV32IM refuse by name, because there the stack belongs to the JS engine or the linker script. A size this cannot read is refused rather than ignored -- a request nobody honours is worse than no request, because the program looks like it asked.

Q-169: `mere doc`. Both halves already existed with no exit between them: --decls knows every top-level name and its inferred type, and doc_above (v0.1.506, hover) knows the comment block a definition was written under. This is those two joined and nothing else. --decls --json gained doc and line, added and not instead of -- decls_json_check.sh still rebuilds the text output from those fields, byte for byte.

An undocumented name is printed with no block under it. Leaving it out would merge "this file does not export that" with "nobody wrote a comment", and the second is what a reader is trying to find. mere doc also lists only the file's OWN names: import splices, so the walk sees the imported file's top-level names too, and --decls prints them on purpose (they are in scope, and that output is for pasting) -- but "what does this file document" must not answer with somebody else's names.

⚠ The comment ceiling went 96 → 53, and finding the rest of it found two defects instead.

The tractable half landed: the comment on an if ... then line was keyed on the THEN-BRANCH's line, and the branch is on the NEXT line, so the key never matched and 42 of these were dropped. It is keyed on the condition's line now. When the branch starts on the then line the source wrote the comment after the BRANCH, and the branch keeps it.

The other half did not, and the reason is worth more than the twelve comments it was about. extern declarations carry a position the parser already keeps, so placing them looked like four lines -- and it destabilised two example files. mere fmt prints the SPLICED program: a file importing contrib/http/query.mere comes back with extern fn http_current_body TWICE, both now in one file, so the name is not a key and whichever line is chosen is right in one pass and wrong in the next.

Which is the small symptom of something larger, now Q-174: mere fmt -i DELETES a file's import lines and writes the imported file's declarations into it. Nine imports became zero and seven externs became nineteen on one example. The idempotence and round-trip gates could not see it -- the inlined output still type-checks and is stable on a second pass. Loc.file already says which declarations came from an import, which is what a fix would read.

And the gate under all of this was not counting its own corpus. lost is a difference taken over the files fmt accepted, so a file that starts being refused leaves BOTH sums and the gate gets greener -- a false pass, which is the one thing a ceiling cannot show. Four of the 291 examples do not format and nothing said so. fmt_comments_check.sh now classifies refusals by reason the way region_params_check.sh does for the same corpus, names the three that are deliberate, fails on one nobody listed, fails on a name that starts formatting again, and holds a floor of 280 measured files. Three poisons, because an impossible ceiling cannot reach a bug that makes the number smaller.

v0.1.519 — 2026-09-23

_The two ceilings v0.1.518 measured are gone, and one of them was not what the last entry said it was._

v0.1.518 wrote that the three non-idempotent files were "a comment moving one indent level" -- placement drifting rather than anything being lost. That was wrong, and it was wrong in the reassuring direction. Measured properly, a comment on line 380 of the first pass is on line 805 of the second: it moved 425 lines, onto code it does not describe. The diff looked like indentation because the - and + lines carried the SAME TEXT and only the leading whitespace differed -- the line numbers were never read.

The cause was that comment placement is decided by source line, and Loc.line counts within its OWN file. import splices another file's declarations in, so the entry file's line 380 and an imported file's line 380 were the same key. Placement now only considers comments whose location carries no file -- the entry file's own.

Three more things, from the same corpus:

• The formatter prints dyn Trait e again. The parser desugars it to

Trait__pack e unconditionally -- it is in the parser, where keep_sugar does not reach -- so the formatter reconstructs it, and only for names the file actually declares as traits.

• Trailing comments survive on match arms and on else if heads. Over the

corpus: 7,584 comment lines in, 7,488 out -- 188 lost → 96. The restriction is narrow on purpose: a comment is only attached where the formatter itself emits the newline, because attaching it to a final arm or a closing else puts the caller's ; inside the comment -- that broke 13 files before the rule was narrowed.

• mere check reports top-level bindings nothing reads, in files that mark their

exports with pub (Q-146). Files that mark nothing stay silent: without pub there is no way to tell a library's surface from dead code, which is exactly why this was deferred in the first place. The gate asks both directions.

fmt_roundtrip_check.sh now runs at CEILING=0 and DRIFT_CEILING=0 over all 293 example files: what mere fmt writes type-checks, and formatting twice gives the same bytes. fmt_comments_check.sh is at LOST_CEILING=96.

v0.1.518 — 2026-09-23

_Q-173 closed to a measured ceiling: keep_sugar guarded the desugaring and nothing else._

Five passes run after it and were not guarded at all -- range-check versioning (Q-108) splitting a loop into f__rvfast / f__rvslow, inner-function uniquifying renaming go to go_uq3, par_map lowering, top-level shadow uniquifying, main reservation. All of them are preparation for CODE GENERATION, and mere fmt printed them back: 19 example files came out carrying names nobody wrote, and formatting the output split the already-split loops again.

That is the sentence v0.1.504 wrote about echo, one layer down -- a formatter that edits the source it formats is a tool people stop running. Formatting skips them now.

Non-idempotent example files: 109 → 3. The three left are a comment moving one indent level on the second pass, which is placement drifting rather than anything being lost -- the inline comments landed by v0.1.511 are put back by source line, and a line moves when the code around it reflows.

scripts/fmt_roundtrip_check.sh owns both questions now, over the whole corpus and with measured ceilings: what the formatter writes still type-checks (1 left, a trait's internal __pack constructor) and formatting twice gives the same file (3 left). fmt_comments_check.sh says in its header that the idempotence question moved -- formatting ONE fixture twice is what let 109 files drift unseen.

v0.1.517 — 2026-09-23

_Q-172: what mere fmt wrote was not a program, and the cause had five layers._

The parser FLATTENS a module -- its members become top-level bindings called M.foo -- and the formatter printed that: let Bignum.base = 1000000000;, which is not syntax. mere fmt -i rewrites in place, so 52 of the 293 example files came back as something the compiler refused. The formatter's own tests were all small single-file samples; the corpus had never been asked.

Putting the block back is a grouping pass, not a tree rewrite: only the binding name loses its prefix, because a qualified self-reference is valid inside the module it names -- the parser registers the module before parsing its body for exactly that. Then four more layers, each found by fixing the one above:

1. Constructors keep their prefix wherever they are USED, and the rule is

the OPPOSITE inside and out. M.C is unspellable inside module M (a parse error in a pattern, unbound in an expression) and REQUIRED outside it -- examples/module_scoping.mere has Red in two modules and tells them apart that way. Stripped inside the block only.

1. A type declared in a module was printed outside it. The declaration

carries no trace of the block, but Top_ctor_alias ("Traffic.Red", "Red") does, so the type goes back where its constructors were declared.

1. That ownership lookup misfired on a shared name. Keeping the last

owner of Red put type Light inside Mood. A type is placed by the first constructor that names exactly ONE module.

1. `A [1, 2]` does not type-check. A list literal is fine as a FUNCTION

argument (sum [1, 2, 3] runs) and not as a constructor's -- both A [] and A [1, 2] come back as constructor A requires an argument. The formatter wrote the bare form in both.

⚠ And parenthesising the literal everywhere broke the self-host cross-validation: contrib/fmt/fmt.mere and this formatter are held to byte-identical output on a set of samples, and that one does not parenthesise the function case. The parens went to the constructor site instead. Two formatters agreeing is what stopped a fix that was too wide.

scripts/fmt_roundtrip_check.sh asks the corpus directly now: every example the compiler accepts is formatted and the OUTPUT handed back to the compiler. 52 → 1, and the one that remains is a trait's internal __pack constructor reaching the output -- a ceiling, measured, so the next cause shows up as the number moving.

v0.1.516 — 2026-09-23

_Q-171: a catch now releases the region it jumped over, on the backend that had never been able to._

A fail raised inside a region R { } and caught by an outer try_or LONGJMPS PAST THE BLOCK'S EXIT, so the release written there never runs. The C backend has carried an active-region stack for exactly this since v0.1.31, and made it release rather than leak in v0.1.301. The LLVM backend had neither, and kept the region struct in an alloca -- on a frame that is gone by the time anyone could free it. The loop segfaulted at a HUNDRED iterations where C ran twenty thousand; Wasm and the interpreter were fine.

Two changes. The struct comes from malloc, and every live block is on an active stack, so a catch releases what it jumped over by depth alone -- try_or and try_or_msg save @__lang_region_active_n on the way in and call @__lang_region_unwind on the failure path.

Simpler than the C version on purpose. This backend REFUSES region loop, so its blocks are strictly LIFO and a release pops the top; C carries a scan-and-shift because its region-loop swap releases the entry under the one just pushed. Porting that too would have been code with no caller.

scripts/region_unwind_check.sh runs the loop on every backend that can build here, at a scale where leaking the 1 MiB block could not fit in memory -- so passing is evidence the blocks come back, not just that the answer is right. Its poison is the shape of the bug: one catch passes on the broken backend too, which is why the gate runs twenty thousand.

⚠ What it does not claim: total memory. Mere reclaims nothing by default, so peak RSS still grows with the iteration count on every backend, and by different amounts (N=50000: C 2.6 MiB, LLVM 9.7 MiB). That is allocation shape, not this bug -- a leaked block would have been fifty gigabytes.

v0.1.515 — 2026-09-23

_Q-173: the formatter escaped five characters and the lexer writes seven._

A carriage return went out of mere fmt as a RAW CR. The lexer reads that as a line break -- newline in string literal -- so 69 of the 315 example files could not be formatted twice. That was the visible half. The other half is worse: formatting the output again DROPPED the byte, so mere fmt -i on a file with CRLF in a string, which is every Redis and HTTP string in contrib, silently changed what the program sends. A formatter that rewrites in place may not lose a byte. \0 had the same hole.

The fix is two lines in escape_string_for_fmt, and the rule behind it is that the set it writes has to be a SUBSET of what the lexer reads back: n t r 0, backslash, quote, and the interpolation braces. Anything else stays a raw byte and round-trips, because the lexer copies unknown bytes through -- only these two were read as something else.

scripts/fmt_comments_check.sh asks the new question directly: a string holding CR, NUL, tab, backslash and a quote keeps its LENGTH through a format, and formatting twice gives the same file. Its fourth poison is the old behaviour -- drop an escape and the length changes.

_And the number it was hiding._ Non-idempotent files went 109 → 52, while the count of files whose output does not PARSE went 21 → 33: a dozen files used to fail at the carriage return before they could reach the other defect. Two independent faults, and the first one was masking the second.

v0.1.514 — 2026-09-23

_Q-166: pub at the top of a file, and the boundary the splice had not erased._

import "path"; splices the imported file's declarations into this one, so after an import there is a single top-level namespace. The language reference drew the obvious conclusion and said file-level visibility had "nothing to enforce": a library's helper was as reachable as the function it was written for, and mere could not report an unread top-level name because it could not tell a file's surface from its insides (Q-146).

The boundary is not gone, though — it is in Loc.t. Every token carries the file it came from, set by the lexer for anything that arrived through an import, which means a REFERENCE can be checked against the file that made the binding. pub let at top level now says the file has decided its surface, and the check is the module one (v0.1.504) one level out.

Opt-in per file, as it is per module: a file that marks nothing exports everything, which is every file written before this. pub stays a contextual keyword — a program that binds it as a name is unaffected.

The rule that keeps it usable: a file that binds the name ITSELF is unaffected by what another file decided about its own copy. The single namespace means two files may bind the same top-level name; without that, one library marking pub would make a common name unusable in a file that never imported it. scripts/file_privacy_check.sh holds all four directions with two poisons — including that removing the marker makes the refused call succeed, so the gate is watching this failure and not some other one.

⚠ This is visibility, not separate compilation. The splice still happens: the program is still one translation unit and mere -c still reads the whole tree. What changed is what may be REFERRED to.

_And the claims gate caught the reference again._ File-level visibility has nothing to enforce is retired wording now. The first row written for the new sentence reported PHRASE GONE from a file that said exactly what it claimed — the phrase had wrapped across a line, and the check is a fixed-string grep per line. The header says so now.

v0.1.513 — 2026-09-23

_Q-167: four spellings the lexer had never heard of, and three of them were name errors rather than syntax errors._

0b1010 came back as `unbound variable: b1010`. The lexer read the 0, stopped, and handed b1010 to the typer as a name — so the diagnostic was true and useless, and nothing in it said "this language has no binary literals". Same for 0o17 and 1_000. int_of_string had understood all three all along, and the digit separators too: what was missing was the lexer, not the conversion.

Binary (0b / 0B), octal (0o / 0O) and _ between digits, in every base and in a float — 1_000_000, 0xFF_FF, 0b1010_1010, 1_000.5. Each _ has to be followed by another digit, so 1_ is still the integer 1 next to an identifier, which is the reading a program that binds _x already relies on.

`\uXXXX` is the one that is not a number. Exactly four hex digits, encoded as UTF-8, so "\u3042" is three bytes and utf8_len counts it as one character. A surrogate half is refused with a sentence rather than written out: it is not a character, str is bytes, and nothing downstream would put a pair back together. Beyond the BMP is written as the character itself — this file is UTF-8 and the lexer copies unknown bytes through.

`scripts/doc_claims_check.sh` caught its own docs. The gate landed two days into its own life with No Unicode escape (\uXXXX) and no octal or binary literal syntax and no digit separator in its catalogue; the moment the lexer learned them, it went red naming docs/language-reference.md:613 and :614 before either sentence had been touched. Both wordings are retired now, which is the other half of the same gate.

_Measured and not fixed._ The self-host lexer (contrib/parser/lexer.mere) splits every one of these into three tokens — including `0xFF`, which this compiler has had since v0.1.46. It was behind before this change and is behind by three more spellings now; that is Q-153's ground, and the number is in it.

v0.1.512 — 2026-09-23

_Q-039: the shift count had four answers, one of them undefined._

bit_shl x n with n at or beyond the width meant four different things. The interpreter defined it. The C backend's << on a signed long long was undefined behaviour — and not theoretically: UBSan on the emitted code says left shift of 4611686018427387904 by 1 places cannot be represented in type 'long long', and a count of 64 or more is undefined on its own. LLVM IR calls a shift by 64 or more poison. Wasm masks the count mod 64 by spec, so bit_shl x 70 quietly meant x << 6 there.

The contract was already written down, in the RISC-V backend: a count at or beyond the width gives zero for a left shift and the sign bit for a right one, chosen there "to match what the other backends give". Three backends had never implemented it. They do now — C shifts in unsigned long long and guards the count, LLVM masks the count so no poison is produced at all and selects, Wasm tests the count before shifting — and the interpreter's one disagreement went with it: a NEGATIVE count used to return x unchanged from bit_shr, which no compiled backend could reproduce because they compare the count as unsigned. One rule, four backends, test/parity/shift_counts.mere.

And the boundary between the two integer widths is pinned rather than avoided. The lexer refuses a literal above 2^62-1 on every backend and says why; nothing enforces that on a computed value, and 2^62 is exactly where the interpreter's 63-bit int and the compiled backends' 64-bit one part company: bit_shl 1 61 is one number everywhere, bit_shl 1 62 is two. test/parity/int_width_boundary.mere declares that difference to the harness, which reads it as DIVERGE — so moving it is a failure rather than a surprise, and the corpus stops quietly staying under 2^62 without saying why.

No `bit_ushr`, and the reason is that boundary rather than effort. A logical right shift is a statement about the top bit, and the top bit is what the two widths disagree about: bit_ushr (-8) 1 is 2^63-4 on the compiled backends, a value the interpreter cannot hold. Documented in the stdlib reference next to the mask convention the varint code here already uses.

v0.1.511 — 2026-09-23

_Q-154: the comments the formatter was still deleting, and two holes found under them._

v0.1.505 taught mere fmt to keep comments written in column 1. The other two kinds were documented as dropped: an indented comment belongs to an expression and the tree has no field for one, a trailing comment belongs after a node whose extent no Loc.t records. The lexer had both all along -- it records a position for every comment and the collector threw away everything that was not in column 1 -- so what was missing was placement, not collection.

Indented comments go back into the run of `let`s they were written in. That run is the one place this formatter emits its own indent, which makes it the one place a comment can be put back without guessing a column; 516 of the 654 in the examples corpus sit directly above a let. Placement uses a watermark rather than draining everything written before the line, so a comment written above a whole block is not dragged down to the second binding -- it falls through to the old fallback and is printed above the declaration. Moved, which this formatter has always preferred to lost.

A trailing comment goes back at the end of the line it was written at, when that line is one the layout emits in one piece -- a let whose value fits, or a one-line declaration. 375 of 636 are on a line that starts with let.

On examples/: 8,181 of 8,426 comment lines survive, against 7,168 before. What is still dropped is a trailing comment on a line the formatter does not emit whole (an else, a match arm, a multi-line binding), and scripts/fmt_comments_check.sh now holds a measured CEILING on the loss rather than a note -- the next slice shows up as the number going down, a regression as it going up, and a third poison proves the ceiling can refuse.

Two properties this arc measured and did not fix, both older than it. On the 315 example files: mere fmt output does not parse for 21 of them, and formatting is not idempotent for 109. The gate's idempotence check formats ONE fixture twice, which is why neither number was visible; it says so now. Both were measured against this compiler with the change stashed, so they are the baseline rather than this slice's doing -- the first version of the indented placement added 47 files to the non-idempotent count, and that was fixed by refusing to write a comment when the buffer cannot know what column the caller left the cursor in.

v0.1.510 — 2026-09-23

_Q-165: a caught failure can say why._

try_or could see THAT something failed and not WHY. What it handed back was the default; the message the raiser wrote went nowhere, and a library written here could not offer "branch on the kind of failure" to its callers -- contrib/url's parse gave up fail and returns ?url_parts for exactly that reason. try_or_msg : (unit -> 'a) -> (str -> 'a) -> 'a applies its handler to the message instead.

What the handler receives is the diagnostic line, the bytes the failure would have written to stderr had nobody caught it: fail "boom" arrives as fail: boom, tag included, and a failure raised inside a backend arrives under its own name. The tag belongs to the fail builtin rather than to the printer, which is why that string is the one every backend already had in hand at the catch -- taking it off would have been four different subtractions to keep equal.

Three of the four had the message and dropped it. The C backend has copied it into __lang_fail_msg since v0.1.67, for the --lib boundary's err buffer, and nothing in the language could read it; LLVM received the pointer in __lang_fail_impl and longjmped without it; Wasm received it and set a flag. They copy it now, into a fixed 256-byte buffer on C and LLVM and into reserved memory on Wasm, because the string the raiser built can be above a bump mark that a block rolls back on the way out. At the catch it is copied AGAIN, into the catcher's region: the buffer is one, and a second failure -- including one raised by the handler -- would rewrite what the handler is reading. try_or's 211 call sites across five repositories are untouched; this is a new name, not a new signature. The RISC-V backend refuses it by name.

The shape that only exists once there is a handler. A handler that fails -- "translate this into my own error", the ordinary reason to want one -- longjmped back into the catch that had just called it, which called it again, forever. try_or cannot have this bug: its default is evaluated before the _setjmp, so nothing on its failure path runs under its own jmpbuf. The catch comes down before the handler runs now. The parity suite found it, as a program that printed three lines fewer on one backend and then did not stop.

test/parity/fail/reason_*.mere is the gate: twelve programs, each writing the same failing expression twice -- once inside try_or_msg, whose handler prints what it was told, and once bare, so the process ends with that same failure. scripts/fail_reason_check.sh compares the two on every backend that can be built here, with a poison that prints a different reason.

_And a hole this arc found but did not fix._ A try_or catching a failure raised inside a region R { }, in a loop, segfaults on the LLVM backend at a hundred iterations where C runs twenty thousand. longjmp skips the block's exit, so @__lang_current_region still points at the region that was jumped over -- the C backend saves and restores it (v0.1.31) and releases what it jumped over (v0.1.301), and this backend has no __lang_region_unwind at all. try_or_msg restores the pointer on its own failure path, because the message it allocates has to land somewhere owned; try_or is unchanged and the hole is recorded rather than patched. It went unseen because nothing in the caught-side parity had ever failed from inside a region block.

v0.1.508 — 2026-09-22

_One rule written in one arm of four twins, and the spelling that never got checked._

`let rec` was skipping two of `let`'s safeguards. A top-level binding can be spelled let f = ..., let rec f = ..., as a member of a let rec ... and ... group, or inside a module. Four loops walk declarations — the interpreter's, type_of, region_param_report and infer_program_inner — and every one of them routed Top_let through infer_top_let and top_let_scheme, then inlined the Top_let_rec case by hand. Both of that pair's checks were therefore missing from all four:

let store = vec_new ();
let keep = fn (n: int) -> ... vec_push store (vec_new ()) ...;   // refused under --lib
let rec keep = fn (n: int) -> ... same ...;                       // compiled

Under --lib each exported call runs in its own region, so the second program put a pointer into memory the next call reuses — the exact fault the boundary check exists to stop, reachable by changing one word. The value restriction had the same hole: let store = vec_new (); is monomorphic, and spelled let rec store = vec_new (); it was generalised, after which one Vec held an int and a str and neither use complained.

Both now go through one entry point, infer_top_rec, which the four loops share the way they already shared infer_top_let.

The gate is about the asymmetry, not the rule. Each property is run in all five spellings and must get the same verdict, so the next rule that lands in one arm fails here even when the arm it landed in is right. It includes a program that must be ACCEPTED in every spelling — a gate whose every check is "this is refused" passes on a compiler that refuses everything — and its poisons are a compiler that refuses only the let spelling, which is the shape of the bug, and one that refuses everything.

This was found sideways: an experiment that grouped adjacent let bindings made a regression test stop refusing what it refuses. The experiment was discarded; the hole it had routed ordinary lets into was older than it.

Counts

dune test 2817, parity 180, and one more gate script with poison runs in CI.

v0.1.507 — 2026-09-22

_The first layer a newcomer hits had twenty-six explanations everywhere else and none of its own._

A syntax error now says what to write instead. The typer, the exhaustiveness checker and the pipeline carry twenty-six help: lines between them; the lexer and the parser carried zero, although the syntax layer is the one a reader meets first. Seventeen spellings borrowed from other languages were tried against the compiler and sixteen came back with a generic message — several of them actively misleading, because var x = 1; and def f(n): both produced trailing input, and Python's a and b produced expected ';' or 'in' after let binding (and is Mere's keyword for a mutual-recursion group):

parse error: expected ';' or 'in' after let binding
  --> x.mere:1:35
  |
1 | let _ = if true then 1 elif false then 2 else 3;
  |                                   ^^^^
  |
  = help: `elif` — chain with `else if`

It is one table, not 149 edits. Parse_error is raised in 149 places and none of them were touched. A hint rides on the message, which already exists; what was missing is the answer to what did the reader actually write, and the token list answers that at the two entry points that parse. The typer reads the same table for the words that get past the parser as unbound names (def, return), where the fuzzy suggestion used to answer did you mean \e\?.

A word is only a keyword if this file does not bind it. var, case, val and mut are real identifiers in the Mere repositories — let var = list_sum ..., fn (case: int) -> case * 2, fn val ->, &mut R v, and as tuple pattern binders, let (val, j) = ... and let (classes, var, prefix, r2) = ... — so the table is given the names the file binds and stays silent about those. of is not in the table at all: it is Mere's own keyword (type t = A | B of int, measured 943 times across 989 source files) and never reaches the parser as an identifier.

The window is the failing line rather than the failing token, because the evidence is often a few tokens back: if c then 1 elif x < 0 then 2 fails at the second then, four tokens past the elif that explains it. Every hint names the token it keyed on, so a reader who was doing something else can see at once that the hint is not about them.

scripts/syntax_hint_check.sh holds all eighteen rows, and its poisons are the risk the design took on: != and let rec ... and are correct Mere and must stay silent, a file that binds one of the four words must not be told about another language, and with the help: lines stripped every row must go red.

Counts

dune test 2810, parity 180, and one more gate script with poison runs in CI.

v0.1.506 — 2026-09-22

_Two diagnostics that were right about what was wrong and silent, or wrong, about where._

A failure inside a prelude function points at the caller. assert, divmod and list_max are written in Mere, so their fail carried a position in <prelude> — a text nobody can open — and the line the person actually wrote appeared only in the stack below:

eval error: fail: assertion failed: boom
  --> <prelude>:539:24              ← before
  --> /tmp/x.mere:1:9               ← now

The innermost frame that is not the prelude's is where they can act, and the backtrace had computed it all along. A builtin implemented in OCaml (char_at) never had the problem, which is why this looked like one oddity rather than a class of them.

Declaring a type twice now says where, twice. The message was good and pointed at nothing at all (Top_type carries no position):

type error: type `t` is declared twice with different constructors
            (`A | B` and `C | D`) (first declared on line 1)
  --> x.mere:3:6

The parser's table records where every type name was declared, and a name declared twice has two entries in it — the caret goes on the second, the message names the first. One location is not enough when the error is about a pair; Gleam spends a whole secondary-label mechanism on this and uses it in fifteen places, which is worth remembering if a second case turns up here.

scripts/diagnostic_position_check.sh holds both, with poisons in the directions that would make it pass for the wrong reason: an OCaml builtin must still point at the user, and a type declared once must not be reported.

Counts

dune test 2800, parity 180, and one more gate script with poison runs in CI.

v0.1.505 — 2026-09-22

_One question that had two answers, and a formatter that deleted what the editor had just started reading._

A `let` that can fail is refused at compile time. let Some n = e; is a match with one arm, and until now the two constructs answered the same question differently: the match was refused with non-exhaustive match (missing None) and the let compiled, then failed at run time with top-level let pattern did not match. The witness comes from the same find_missing the match uses, so the error names the value that does not match:

error: this `let` pattern does not match every value (missing None)
  = help: write it as a `match` with an arm for None
  = note: a `let` binds; it has no other arm to take when the pattern does not
    match, so this would fail at run time

What stays free: let (a, b) = ..., record patterns, a plain name, and a constructor pattern on a type that has only one constructor — that one is total, and refusing it would be refusing the ordinary way to open a wrapper. if let is untouched: the parser turns it into a two-armed match, which is the construct for a pattern that may not match.

⚠ THE SAME SPLIT REAPPEARED ONE LAYER IN. With the check written, mere check and every emit path refused the program while the interpreter still failed at run time — because it walks declarations and RUNS each one as it goes, so a refutable let reached its own failure before anything drained the findings. The findings are now drained before each declaration is evaluated, and all three paths give the same answer.

Measured before writing it: zero refutable lets in this repository, mere-ruby, mbrowse, medit2 and m3d. The sixteen places that look like one are all if let.

`mere fmt` keeps the comments in column 1. It used to delete every comment in the file. That was written down as an MVP limitation and it was survivable while nothing else depended on comments — and then v0.1.504 taught hover to read the block above a definition, so one half of the toolchain was reading what the other half deleted. textDocument/formatting is the same function, so format-on-save was the delete.

Column 1 only, and the reason is a measurement: of the 23,452 comment lines in this repository's .mere files, 19,338 (82%) start in column 1 — and those are exactly the blocks hover reads. The other two kinds need something the tree does not have: an indented comment belongs to an expression, and a trailing one belongs after a node whose extent no Loc.t records.

The material was already there: the lexer has been able to collect comments since semantic tokens needed them, and it records a position and a width, so the text is a slice of its own line. Nothing had asked for them.

⚠ Most top-level declarations carry no position at all — only Top_let, Top_let_rec and Top_forward do, which is why Parser.declared_types exists for the rest. A declaration that cannot be placed does not collect the comments above it; they go to the next one that can. Losing a comment is not an option, moving one down is the fallback, and it is written down here rather than discovered later.

scripts/fmt_comments_check.sh holds three things: a column-1 comment survives and stays above its declaration, formatting is idempotent, and over examples/ the count of column-1 comment lines does not go down — 287 files, 6,316 lines in, 6,316 out. It also prints what is still dropped (~612 indented lines in examples/) so that the remainder stays visible rather than forgotten.

Counts

dune test 2796 → 2800, and two more gate scripts with poison runs in CI (refutable_let_check, fmt_comments_check).

v0.1.504 — 2026-09-22

_The second pass over Gleam: four answers the compiler already had, a flag that makes yesterday's warnings mean something, a machine-readable API surface, one pattern, and pub._

_The previous pass's five landed in v0.1.503; this is the outside of that circle, chosen by the same rule — take what is a wire rather than a new analysis — plus one thing that was measured and dropped (below)._

Four LSP answers, none of them new work. The server advertised nine providers; Gleam enables twelve. Three of the four missing ones had their answer sitting in this repository already:

The fourth, foldingRange, is not in this release and is not an oversight: a Loc.t is a start and a width, so nothing in the tree knows where a declaration ends. That is the same missing fact that stopped the redundant-arm quickfix in v0.1.503.

Two things the hover did not do, and now does. It answered nothing on a definition — Query.node_at looks for an expression and the inc in let inc = ... is a pattern, so hovering the place a name is introduced returned nothing at all. And it showed no documentation: the contiguous // lines above a definition are now part of the hover, found through the binding, so hovering a USE shows what was written at the DEFINITION. No /// marker, because Mere has no docs generator for one to feed — requiring a third slash would mean every comment already written shows nothing.

⚠ Signature help needs one guess and says so: without extents, "the call the cursor is inside" is not a question the tree can answer. It answers about the nearest call head at or before the cursor on that line, preferring a call that is still unfinished — which is what stops add3 (pick Red) from reporting about pick.

`--warnings-as-errors`. v0.1.503 gave the compiler warnings worth acting on (an unread binding, a deprecated name) and no way to make a machine act on them, so a CI could not hold the line against new ones. The rule is one rule: everything is printed exactly as it would have been, and then the status is 1. The count is of warnings produced, not printed — a file with twelve of them fails even though the terminal shows ten and a summary.

A machine-readable API surface. mere --decls --json prints what --decls prints, plus the type declarations and their constructors, plus the package's declared floor — the same pairing Gleam's package-interface has, where the version constraint sits beside the interface. What it is for is the diff between two versions of a package, which is the question mere fix raised in v0.1.503 and could not answer.

The two outputs are two renderings of one walk, and scripts/decls_json_check.sh is what keeps that true: it rebuilds the text from the JSON and compares byte for byte across the whole parity corpus — 179 files, 32 of them carrying a commented-out declaration, which are the entries nobody writes by hand.

`| "lit" <> rest ->`. The prefix test and the slice that always followed it, as one pattern. In contrib/ alone there were 38 str_starts_with calls, 13 of them followed within two lines by a slice; that shape is now:

match url with
| "https://" <> rest -> secure rest
| "http://" <> rest -> plain rest
| other -> none other

It is a node only as far as Pipeline's desugar, which rewrites the arm into a guard and a binding over str_starts_with / utf8_sub / utf8_len. No backend knows the syntax exists, and a guarded arm closes nothing, so the exhaustiveness checker already says what it should: a prefix arm does not make a match total.

⚠ It is an AST node rather than a rewrite inside the parser for one reason: the formatter. Which is how the next entry was found.

The formatter was rewriting the source it formatted. echo is lowered to echo_at "<where>" while parsing — and the formatter parses. For one release mere fmt on a file containing echo x printed echo_at "line 2" x: correct, equivalent, and not what the person wrote. Sugar lowering is now skipped on that one path (parse_program ~keep_sugar:true), with a test that says so.

`pub`, inside a module. module M { pub let get = ...; let helper = ...; } — M.get is callable from outside and M.helper is not, by name:

type error: `Store.secret` is internal to module `Store` (the module marks its exports with `pub`)

Opt-in per module, because it has to be: every module written before this marks nothing, and making unmarked mean private would have made all of them export nothing. A module that marks nothing is unchanged; one mark says the module has decided what its surface is. pub is not a keyword either — it is an identifier the module-body parser recognises in front of let, so nothing that uses pub as a name stops lexing.

⚠ This is not what Q-146 wanted, and reading the parser is what settled it. File-level visibility has nothing to enforce: import "path" is a SPLICE (parser.ml, the imported file's declarations are prepended to this one's), so after an import every name is in one top-level namespace. pub works inside module M { } because that boundary already exists. The file boundary does not, and cannot be added without the separate-compilation change the design notes have been holding since the last measurement of it. "Add pub and Q-146 closes" was half right.

Measured, and dropped

Gleam compiles patterns through a decision tree; Mere emits a linear chain of tag tests, and never emits `br_table` — zero occurrences in a whole Wasm module. That looks like something worth fixing. It is not, at the sizes anyone writes:

⚠ The first two attempts at this were not measurements: constant folding deleted the loop and printed 0.00 s. Only after the scrutinee came out of a 4,096-entry table did any work survive. The negative result is recorded in the note so the static fact does not produce the same proposal again.

Counts

parity 179 → 180, dune test 2784 → 2796, and three more gate scripts with poison runs in CI (warnings_as_errors_check, decls_json_check, module_privacy_check).

v0.1.503 — 2026-09-22

_Five things Gleam has, in Mere's spelling — and the four bugs that writing them found._

_Read gleam-lang/gleam at v1.18.0 next to this compiler and took the parts that are configuration of what Mere already computes rather than work Mere has not done. The plan, its measurements and what was deliberately NOT taken are in the internal note; what landed is below. Four of the five needed no new analysis at all._

Code actions (`textDocument/codeAction`). Gleam's language server builds 49 of them; this one advertised eight providers and none. It was not missing an analysis — it was missing a wire. Exhaustive has always known the arm to write (it prints it on the help: line), rename has always built a WorkspaceEdit, and Query has always resolved a position. What was in between was a string: classify flattened its findings to (loc, message) and Pipeline.diagnostic carried nothing else, so the arm died one function before anything could apply it. A finding now carries a fix — a title, a position, a width and the text — and three actions are built from answers that were already there: add the missing arm(s), declare a top-level binding's inferred type (let fn f: (shape -> int);, Mere's spelling of an annotation), and prefix an unread binding with `_`.

⚠ The plumbing changes NO output: the same bytes on stderr, the same exit codes, every gate green before and after. Its only witness is a unit test that reads the fix off a diagnostic, and scripts/lsp_smoke.sh now drives a whole round trip — ask for the actions, APPLY the edit that comes back, and require the file to compile where it did not before, with two poisons (apply nothing; apply at the wrong position) that must both leave it refused.

Unused bindings. Gleam has thirteen Unused* warnings. Mere had four warnings in total, all of them the same kind — a top-level name that collides with libc, an extern whose arity disagrees — which is to say the compile error you are about to get, and nothing about code that is simply dead. The check is built on Query.occurrences, the scope-resolving walker hover and rename already use, so shadowing is answered by the same code that answers it for go-to-definition rather than by a second opinion. Local `let` bindings and `match` binders only: a top-level name in a file that is imported has its readers in another file, and with no pub in the language there is nothing to tell a library's surface from dead code. One rule is borrowed wholesale from Gleam and worth naming — nothing is reported for a file that did not type-check, because "nothing reads this" in a half-inferred tree is usually "the line that reads it is the one being typed".

Pointed at mere-ruby's 32,832-line main.mere it answers 462, every one of them true and most of them one idiom: let (meths, sup, ocls, ivars) = world where the arm uses one of the four. Which produced the other half of this change — a terminal prints at most ten warning blocks and then says how many more there are. 462 blocks is four thousand lines of stderr in front of whatever the person ran the compiler to see; the editor draws all of them in the margin, where they cost nothing.

A compiler version in `mere.toml`. [package] mere = ">= 0.1.480" is now read, and checked against the compiler that is running — by mere install (for the package and for every dependency it fetches) and by every build of a file inside the package. Before this, a package needing newer syntax failed on an older compiler as a parse error in somebody else's file: true, useless, and unactionable without knowing the language's history.

The other half is mere fix, which is Gleam's gleam fix — a command that does exactly one thing: it makes the declared floor true. Feature.all maps a feature to the version it landed in (bytes 0.1.278, the 128-bit lane types 0.1.422, f32x4 0.1.445), the parser notes them where the names are already recognised, and mere fix writes the highest into the nearest manifest.

⚠ A table of versions is a claim about history, which is the kind of thing that is right the day it is written and never looked at again. scripts/version_floor_check.sh re-derives every row from `docs/changelog.md` — oldest mention of the feature's probe word, version of the section it sits in — and fails when a row disagrees with the record it came from. Rewriting one row's version by hand turns it red, which is how that sentence is known to be true.

Deprecation, without an attribute. Gleam marks a deprecation on the definition. Mere has no attribute syntax and adding one costs two parsers, this one and the self-hosted one, so the mechanism is a table keyed on the names the compiler itself ships, matched only where the name resolves to the builtin (a user who binds str_len themselves is not told about their own name). The table is empty, and that is a measurement rather than a placeholder: all 281 entries of initial_env were compared for the pairs a rename leaves behind and there are none. The tests install a row to drive the path end to end.

`echo`. echo x prints x to stderr with the line it was written on and answers x, so it drops into the middle of an expression and comes out again without moving anything. Two prelude functions and one pass — no backend knows about it, and all five have it.

⚠ The first version rewrote the token in the parser, which is simpler and wrong: test/parity/graphql_stack_portable.mere binds echo as a name of its own, and rewriting every occurrence turned its value into a partial application. The rewrite now runs over the parsed tree with scope tracked, and an echo the user bound means what they said.

The four bugs that only appeared when it ran

None of these is visible from reading. Each was found by the same program being asked to print the same thing on five backends.

scripts/echo_check.sh is the gate, and it compares stderr across interp / C / LLVM / Wasm / RISC-V, because a debug print that reached stdout would be changing the answer it is watching. The RISC-V row has a stated exception: the emulator's write ignores the descriptor, so the guest's fd 2 arrives on fd 1 and the two streams are put back together before comparing — a fact about the emulator, written down rather than left as a filter.

Counts

parity 178 → 179 programs (the new case is echo, whose value must pass through unchanged on every backend), dune test 2767 → 2784, and four gate scripts with poison runs in CI: unused_check, version_floor_check, echo_check, plus lsp_smoke --poison, which did not exist.

v0.1.502 — 2026-09-22

_The rest of the class, and a check that keeps it out._

_v0.1.501 fixed the six harnesses that had gone RED when Q-136 removed the trailing unit line. It left the ones that were still GREEN, on the grounds that they were correct — their probes end with a bare 0, a real value the trim really does remove. That is true and it is not a good enough reason to keep them: a harness that drops its subject's last line can compare the wrong thing and pass, and the only thing standing between "correct" and "silently wrong" is whether someone remembers the sentinel when they edit the probe._

_So the pair is gone everywhere. Nine more gates print exactly what is compared. In url_parity the sentinel had leaked into the oracle — node was printing a matching 0 — which is how far this kind of thing travels._

_Three trims turned out to be doing something other than what they said:_

_Four uses are left and each is named in the new gate with its reason: the diagnostic payload parity.sh READS off the last line, the generated source exhaustive_check.sh splices an arm into, the ---MARK--- line live_soundness_check.sh drops from psql, and rv_exec_check's documented "an RV binary never prints the program's own final value" — which is still load-bearing: run against the emulator, 19 of 96 programs match only after it._

_scripts/trailing_trim_check.sh keeps the class out, with two poisons. ⚠ It found three violations older than itself the first time it ran, in a file six hand-written greps had missed. ⚠ And its own first pattern used \? in a basic regexp, which BSD grep does not take, so on macOS it matched nothing and reported ok — the poison is the only reason that was caught._

v0.1.501 — 2026-09-21

_The workarounds v0.1.494 left behind, and the sixth place that decides what a program prints._

_CI had been red for seven commits. Every run failed the same eleven steps, and the first red one was v0.1.494 — Q-136, "a program whose value is unit prints nothing". That commit said the rule lived in five places and changed all five. It was wrong twice._

_Wrong about the harnesses. Six gates carried sed '$d' on the subject's output: until v0.1.494 every Mere program printed a trailing line for its own value, and these dropped it. Afterwards they dropped the answer. The clearest case is proto_parity, whose whole-message check reported_

  FAIL  message (interp)
        protoc: 08ac0210ffffffffffffffffff01180322026869380142040102ac02
        ours:

_— not a wrong encoding, an erased one. proto_gen_parity was worse: the same trim ran on the GENERATED SOURCE, so hello_pb.mere came out a line short of itself. render_agreement lost the last element of the server's tree and reported the client as having one extra._

_The probes that were still green show what the shape was: they end with a bare 0, a sentinel whose only job was to give the trim something to eat. Sentinel and trim are both gone now — the probes print exactly what is compared._

_Wrong about the count. There is a sixth place, and selfhost_check is what found it: the Mere compiler written in Mere still wrapped every program as let _ = print (show (main : main_ty)) in (). All seven of its equivalence cases were one line apart from the reference for seven commits._

_The rest were stale records — () sitting in test/boundary/EXPECTED, four test/vclock/*.expected, and the transcripts inside audio_check.sh and io_poll_check.sh._

_⚠ None of this was Linux-specific. All eleven reproduce on a development machine; they were simply not in the set anyone was running before pushing. Running the CI gate list locally — all 100 of them — is what this slice actually cost, and it found one more thing: width_check builds a Ruby comparison that read EastAsianWidth.txt in the caller's locale, so it died on a shell with LANG unset while CI, which sets UTF-8, never saw it. The encoding is stated at the read now._

_⚠ Six gates still carry a sentinel-and-trim pair. They are green and correct — their sentinel is a non-unit value that really is printed — and they are left alone, but a harness that drops its subject's last line can compare the wrong thing and pass, which is why the six that broke were rewritten rather than re-sentinelled._

v0.1.500 — 2026-09-21

_Floats stop being boxed at every node on the Wasm backend._

_Q-140 and v0.1.499 both came from asking the examples corpus a question nothing else asked. Sweeping it a third time — this time for allocation, not output — found examples/mandelbrot.mere dying with "out of memory" on Wasm and nowhere else: C reports alloc_total=6,291,736, Wasm used up the whole 64 MB linear memory._

_Isolating it took one probe and one control. 100,000 iterations of acc + (1.0 / (1.0 + (2.0 * 3.0))):_

          Wasm          C
float     6,400,036 B   32 B      <- 64 bytes an iteration
int              30 B    0 B      <- the control: the loop itself is free

_The control is what makes this a measurement rather than a guess: it is not the loop and it is not the Vec, it is the float. This backend keeps every value in an i64 slot, so a float is the address of an 8-byte box, and until now one was minted at every node — four literals and four results, eight boxes, to compute one accumulator._

_Three places the box is not needed, in the order they were removed:_

_8×, and the 8 bytes left are the accumulator itself: the floor for a boxed value model. pi and e were allocating on every read too, and go the same way._

_No new mechanism — Q-109 had already built this shape for SIMD, so emit_float_f64 / float_locals / Ast.float_operand_only are emit_simd_v / simd_locals / Ast.simd_operand_only with the width changed._

_⚠ The predicate decides whether the unboxing pays, never whether the code is correct. An f64 local asked for its address gets boxed on the spot by its own arm in emit_expr. Resting correctness on an analysis that has to be conservative is how an analysis that is slightly wrong becomes a wrong answer._

_⚠ Nothing else in the tree could have caught this, and nothing else guards it now. The answers are bit-identical either way: examples/raytrace.mere writes the same 56,610-byte PPM and the same adler=48497-22482 before and after. The suite, parity, main_value_check and the size budgets are all green on the slow version. So the gate is the allocation meter — scripts/alloc_meter_check.sh check 6, with a ceiling and a floor: the ceiling catches boxing coming back, the floor says floats are still boxed at all, so the day that stops being true somebody has to come here and write it down._

_raytrace.wasm, where every vector is a (float, float, float), went 9,530 → 6,107 B (-36%) and broke its band's floor — which is the floor doing its job. Lowered deliberately, after checking the module still answers what the interpreter does, byte for byte._

_mandelbrot still does not run, and measuring why produced a different question. Reduced to 80×60 so it completes (the alloc_total of a program that hits the wall is how much fit, not how much it wanted), it went 22,133,389 → 13,702,001 B — 1.6×, not 8×. The same recursive loop at top level costs 16 B/iteration; nested inside a function that captures, 103 B/iteration, with an int control at 1.67. Counting bump sites per function in the WAT, the nested build alone carries $anon_1_fn and $anon_0_fn_fn2; the lifted body is identical. That is Q-139's __direct/fn2 not reaching a capturing inner function, and it is not a float question — filed separately._

_What remains genuinely float-shaped is the calling convention: an argument is a Mere value, so a float argument is an address, and two of them cost 16 bytes a call. Changing that is a different slice._

v0.1.499 — 2026-09-21

_The examples corpus is compared across backends, and the first run found a bug._

_Q-140 closed one un-gated path — what a program prints when it ends. The question it raised was how many others there are, and guessing at source was not going to answer it: the four backends hold 446 catch-all arms that produce a value rather than refusing._

_So the corpus was asked instead. examples/ holds 291 programs written for people, and nothing compared them across backends — check_cmd_check.sh sweeps the same tree but asks only whether a program is ACCEPTED, never what it prints. Running them on the interpreter and on C and diffing found, on the first pass:_

examples/vec_higher_order.mere
  xs:      Vec[1, 2, 3, 4, 5]        (interpreter)
  xs:      <unknown>                 (C backend)

_`show` of a `Vec`, wrong on a shipped example, for as long as both had existed. And the same four-way split as Q-140 underneath it: interpreter Vec[1, 2], C <unknown>, LLVM a refusal, Wasm a function whose whole body was `(unreachable)` — a program that compiled, ran, and died with no message._

_C displays a Vec now, walking the elements and asking each one's own show, the way the list arm a few cases above it already did. ⚠ The arm had to go BEFORE the general `TyCon` one, which was swallowing it — OCaml's "this match case is unused" said so, which is the same check this compiler grew for Mere in v0.1.487._

_Wasm refuses instead of trapping. A type with no constructors is not a variant, and the tag chain collapses to a bare (unreachable); saying so at compile time is what LLVM already did and beats dying silently at run time. So the four now read: display, display, refuse, refuse — and none of them lies._

_scripts/examples_parity.sh is the gate. It selects by asking rather than by listing: an example is compared when the interpreter finishes it unattended AND its output is a function of the program. ⚠ That second question is asked after the C build, not beside the first run — back to back, two interpreter runs land in the same second and a per-second clock looks stable, which is exactly how log_levels_demo.mere slipped through the first version. The gap is the build, so nothing here is a fixed sleep guessing at the machine._

_186 compared, 89 skipped (input, ports, time), 1 not a function of the program, 15 refused by the C backend. The gate fails if fewer than 150 are compared: a corpus that quietly stops being swept passes forever._

_suite 2773, parity 196 PASS / 0 FAIL._

v0.1.498 — 2026-09-21

_Q-140: one rule for what a program prints when it ends._

_The same program, four answers:_

_That last cell is a POINTER printed as a decimal integer: main_format_of's catch-all was %d, so anything the table did not name became an int. The tuple row is the same thing printing its first field. Three backends had three different wrong answers and nothing could see it, because `parity.sh` runs programs that end with `print` — the path that displays the program's own value is one almost nothing exercises._

_`show` already agreed with the interpreter on every one of them. It was simply not on this path. So the rule is one line now, on all four: the program's value is displayed the way show displays it, which is what Eval.to_string has always done. Nine programs, four backends, one answer._

_⚠ A main whose type never resolved has no value to display. The common case is a program ending in exit 0, whose type is a variable because the call does not return — asking show for a 'a is a refusal, and it took down the whole suite the first time. The interpreter exits inside the evaluation and prints nothing, so printing nothing is what agrees with it._

_Seven assertions moved. Every one pinned a lowering (printf("%lld\n", 42LL), zext i1, @printf(ptr @.fmt_s, ...)) rather than an answer, and each was re-pinned at the new lowering with its question intact — except the zext, whose question stopped existing when printf did: the value now crosses to show_bool as an i1, so there is nothing to widen, and what is asked instead is that it crosses at its own width._

_scripts/main_value_check.sh is the gate, with a poison that rewrites one backend's answer and requires the comparison to catch it. It is in CI, because this is precisely the kind of drift that survives for years when no gate runs the shape._

_suite 2773, parity 196 PASS / 0 FAIL._

v0.1.497 — 2026-09-21

_Q-139 closed: every cell of the table is zero, on all three backends._

_Two rows were left, and NEITHER was the closure mechanism any more. Reading each one before touching it is the whole of why this is one slice._

_A capture-free top-level fn used as a value is a CONSTANT. ap add acc i in a loop built the same twelve-byte record every iteration — env 0 and two table indices known at emit time. It goes in the data segment once now, and the expression is a constant. Twelve bytes a call to nothing._

_And the last eight bytes an element were the merge sort's scratch, not a closure at all: n slots taken from the bump heap and left there. The C backend malloc/frees its scratch and its comment says exactly why — "a region alloc would leave n slots behind on every call" — and the Wasm backend had no such escape, so it simply left them._

_⚠ It is only given back when nothing was allocated after it. A comparator can allocate: the two-step path builds an environment, and a user's comparator can push to a Vec it captured, whose buffer may have been reallocated above the scratch. Resetting the bump past any of that hands out memory something still holds. The test is the honest one — the scratch is reclaimable exactly when the bump is still where the sort left it — and a probe whose comparator pushes on every comparison answers the same on all four backends._

_⚠ `$src` and `$dst` are swapped once per pass, and at the end $dst has been pointed at the vec's own buffer for the copy-back, so neither still names the block that was allocated. The first version compared against $dst and reclaimed nothing at all, silently._

_Q-139 took six slices: three on LLVM (v0.1.491-493) and three on Wasm (v0.1.495-497). It started because the allocation meter (Q-138, v0.1.488) made the question askable, and the first answer it gave was that Q-135's fix had been C-only — which nothing could have known before._

_suite 2773, parity 196 PASS / 0 FAIL, wasm 558 KB against 616 KB before the arc, every gate green._

v0.1.496 — 2026-09-21

_Q-139 on Wasm, second half: a closure value carries the uncurried entry._

_Three pieces, the same three the LLVM backend needed: a two-argument adapter for an anonymous lambda whose body is immediately another fn (registered in the table beside the one-argument one, so the value and the adapter are decided by the same test); the fn2 index written into the closure record; and the branch in each of the three higher-order helpers — vec_fold, map_iter (BOTH variants, the linear one and the tombstoned one) and vec_sort._

_The comparator in a merge sort is asked n log n times — 1.7 million for the 100,000 the board measures — and every ask built an environment to carry the first element: 28.6 MB to 1.85 MB. The order and the count are unchanged, and test/parity/vec_sort_stable and closure_fn2_order both say so on this backend now as well as on the others._

_The trait row came free with the anonymous adapter: a dictionary field holds a lambda, so once lambdas carry fn2 the dictionary does, and the saturated closure-call path already admitted a field read as a head._

_Size: 522 KB to 558 KB — the adapters and branches are real code — against 616 KB before the arc. The bands are set to this settled state, measured once rather than chased slice by slice._

_What is left of Q-139 is two rows at 12 and 8 bytes, both on Wasm, and neither is the closure-value mechanism any more: something else allocates on those paths. The table is the gate, and it now reads zero in nineteen of twenty-four cells._

_suite 2773, parity 196 PASS / 0 FAIL, size and budget gates green._

v0.1.495 — 2026-09-21

_Q-139 on Wasm: the uncurried entry, and the shipped modules get 15% smaller._

_The third backend gets the mechanism the other two have. On Wasm it also turned out to be a size question, and the answer was the opposite of what the first attempt measured._

_The closure record is twelve bytes now, { i32 env, i32 fn_idx, i32 fn2 }, with the uncurried entry LAST so the host is untouched — scripts/mere_host.js reads env at +0 and fn_idx at +4 and neither moved. The absent value is -1, not 0: fn2 is a table index and index 0 is a real function._

_⚠ Six hand-written closure records in the runtime WAT kept the old width, and the eight bytes after them were read as a table index and jumped through. test/parity/logger_metrics_caps found it: the program printed three log lines and then "out of memory". Widening a record means every construction, including the ones written by hand in a string._

_And then the size gate refused it. The twins took the shipped modules from 616 KB to 769 KB, six of fifteen over their ceilings. The cause was not the twins: a `_closure` adapter was emitted for every top-level fn, the elem table it sits in is a root the pruner cannot see past, and so every curried body shipped whether or not anything could reach it. Emit the adapter only for fns actually used as values, and the curried body only when something can still enter it — a fn with a twin, never used as a value and never applied to fewer arguments than the twin takes, has no way in — and the pruner does the rest._

_Result: 522 KB, down from 616 KB before any of this. gameboy −29%, raytrace −26%, chip8 −22%, selfhost-tyck −19%. Every band in scripts/wasm_size_budget.txt and test/budget/BUDGETS moved DOWN, which is the floor half of those gates doing exactly its job: "a demo this much smaller than recorded probably stopped being built properly; if it is a real improvement, lower the band". It was checked before the bands moved — suite 2773, parity 196/0, the bootstrap tests that RUN the self-hosted compiler under node, and the size gate's own behaviour check._

_⚠ Two things had to be excluded, and both were found by breakage, not by reading. A monomorphised instance gets no twin: its calls arrive under a mangled name the collectors cannot see, so giving it one dropped a curried body that the multi-instance dispatch still called, and wat2wasm named the missing function. And the saturated closure-call path only takes a head that is already a VALUE — a local or a field — because a partially applied multi-instantiated fn has no value form on this backend, and asking for one is a refusal that surfaced as the self-hosting bootstrap failing to emit._

_⚠ A measurement taken while the tree was being edited is not a measurement. The first verification of this ran in the background while the next slice was still landing, and reported three parity failures that did not exist. Re-run on a settled tree: 2773 / 196 / 0._

_What remains of Q-139 is the Wasm closure-value half — fn2 is carried by top-level fn values but not yet by anonymous lambdas or dictionary fields, so the callback rows still allocate. The table is the gate._

v0.1.494 — 2026-09-21

_Q-136: a program whose value is unit prints nothing._

_() was printed by all four backends from Phase 25.11 / 27.0, to keep the interpreter and the compiled backends saying the same thing. They still say the same thing; they say nothing._

_What it cost. Anything comparing output exactly — a judge, a diff, a golden file — saw an unconditional mismatch on every program whose main is unit, which is every program that ends by printing its answer. All twelve solutions on the mjudge board carry let _ = exit 0; as their last line for no other reason, and one of them carries a comment explaining why. Everybody writing the same line to switch a default off is the evidence that the default points the wrong way._

_Five places decide this and all five changed, which is why it is one slice: Pipeline for the interpreter, main_format_of in the C and LLVM backends, the TyUnit arm of the Wasm epilogue, and the LLVM format global that fed the call. Checked end to end on all four: print "answer" now writes answer\n and nothing else, byte for byte, on interp / C / LLVM / Wasm._

_⚠ `Eval.to_string` is NOT where this changed. show () goes through it and has to keep answering (). The decision belongs to "what does a program print when it ends", so it sits at the end of Pipeline.process — which now has an option-shaped twin, process_opt, because "nothing to print" and "print an empty line" are different answers and a str main whose value is "" still gets its newline. process stays a string for its six hundred callers; one rule, two spellings._

_Four golden files and twenty assertions moved with it. The two that pinned the OLD behaviour were re-pinned at the new one rather than deleted — the question "does a unit main print anything" is still worth asking, and now it has the other answer._

_The `()` was there for a parity that does not actually hold, which came out while measuring this: a str-typed main prints "abc" — with the quotes — on the interpreter and abc on the compiled backends, and no gate notices, because parity programs end with print rather than with a bare value. Recorded as its own question rather than fixed here._

_suite 2773, parity 196 PASS / 0 FAIL, ten gates green._

v0.1.493 — 2026-09-21

_Q-139, third slice: the LLVM backend allocates nothing where the C backend allocates nothing._

_The three rows had three different causes, and reading each one before touching it is the only reason this took one slice instead of three._

_The builtin higher-order helpers are emitted IR text, and their loops did the two-step call — vec_fold, map_iter and vec_sort, which is the whole surface: three sites. A merge sort asks its comparator n log n times, 1.7 million for the 100,000 the board measures, and every ask built an environment to carry the first element._

_Then the numbers did not move, because the callback in vec_fold v 0 (fn a -> fn b -> a + b) is an ANONYMOUS LAMBDA and those carried null. The C backend added __anon_N_fn2 for this in v0.1.482; this adds the LLVM equivalent. The condition is "the body is immediately another fn", which is the same question the order pin asks: if anything happens before the inner fn is returned, that work belongs between the two arguments and an entry taking both at once cannot express it._

_And the trait row was not about the value at all. The dictionary already carried fn2 — @anon_23_fn_fn2 sat in field 2 of @mu_Ord2__int__dict — and nothing was willing to look, because the call-site guard admitted only a Var head and a trait method is exactly what a Var is not: it elaborates to a read from the instance's dictionary. A field read is always a value and never a builtin, so those heads are admitted now. One row that looked like the other two was a missing line in a guard._

_suite 2773, parity 196 PASS / 0 FAIL, twelve gates green. Wasm is what remains of Q-139: it has none of this, and its column is unchanged at 32 / 67 / 230._

v0.1.492 — 2026-09-21

_Q-139, second slice: the uncurried entry becomes N-ary, and a closure value carries one._

_Two changes, and the second was measured into existence rather than assumed._

_N-ary, not exactly two. The first slice took exactly two parameters, because that is where the meter had pointed. ap add acc i is a THREE-argument spine, so its first application still built an environment per iteration — the whole of that row. Opening the twin to two or more took it from 56 to 8 bytes a call._

_And a closure value now carries `fn2`, the uncurried entry, the way the C backend's does since Q-135. The layout is { ptr env, ptr fn, ptr fn2 }, and null is a real case, not a defensive one: a partial application, a polymorphic value, an eta adapter and anything with a region parameter all carry null and take the two-step path, which is the path every closure call took before this. So the choice is a branch at runtime, not a decision at emit time. Every construction starts from zeroinitializer rather than undef for that reason — an undef field here is a pointer that would be CALLED._

_Worth its width, and checked by removing it: with the fn2 path disabled and everything else in place, the same row reads 8; with it, 0._

_⚠ Two things went wrong, and the tree caught both._

_The arm took over calls that were not the user's. emit_user_app is also the fallback for shapes the builtin arms declined, so a partially applied BUILTIN — channel_recv_timeout c ms — came through it and produced a different refusal than the one the suite pins. The arm was right about the shape and wrong about whose call it was; it now requires a user-bound head._

_And it changed evaluation order. The second argument was evaluated before the branch, but on the two-step path the FIRST application runs first, and a body that is not immediately another fn can print before the second argument is reached. test/parity/closure_fn2_order.mere holds noisy 1 (loud 2), whose prints must read "mid" then "arg", and this printed them the other way round. That file was written for the C backend's own version of this change and it caught this one on its first run. The second argument is now evaluated inside each branch._

_suite 2773, parity 196 PASS / 0 FAIL, ten gates green._

v0.1.491 — 2026-09-21

_Q-139, first slice: the uncurried entry reaches the LLVM backend._

_`__direct` existed in `codegen_c.ml` and nowhere else, and nothing could see that until this backend had an allocation meter (v0.1.488). What the meter said, for a named top-level function at a concrete type applied to both its arguments — the row that is zero on C by construction:_

B/call                               C   LLVM   Wasm
f a b (named top-level, concrete)    0     16     32

_A two-argument call compiled here to "allocate an environment holding the first argument, return a closure, apply it to the second". So on this backend it was never abstraction that allocated; it was the call._

_Same shape as the C table: for an eligible f = fn p1 -> fn p2 -> body, emit @mu_f__direct(p1, p2) holding the body, and send exactly-saturated call sites straight to it. The curried definition is still emitted beside it — this adds an entry rather than replacing one, so partial application and first-class use are untouched._

_Conservative on purpose for a first slice: exactly two parameters, no region parameters, concrete throughout, not an inner lift, head not shadowed by a local, arity matching exactly._

_⚠ Rerouting a call also reroutes it away from `musttail`. The first version emitted a bare call, and the two v0.1.451 assertions went red immediately: they ask a two-argument let rec for musttail call %w and got a bare call. That is not a cosmetic loss — a tail-recursive function without the guarantee grows the stack once per iteration, which is the defect the C backend records against its own single-argument case. The twin now publishes its own prototype (two i64 arguments, not the curried (ptr, T)), which is what lets the self tail call inside it match and become musttail; wide aggregate returns still take notail, because tail on an sret call is the Q-129 miscompile. A two-argument tail-recursive function had no constant-space form on this backend before this._

_The rest of Q-139 is the closure-value half — the equivalent of Q-135's fn2 slices — and the Wasm backend, which has none of this yet. Both stay open, with the table as the gate._

_suite 2773, parity 196 PASS / 0 FAIL, musttail_budget / debug_info / determinism / stack_overflow / vectorize green._

v0.1.490 — 2026-09-21

_The Wasm meter was silent for every program that ends by exiting._

_`exit n` reaches the Wasm host as `exit_proc`, which calls `process.exit` and never comes back, so the line that reported allocation was never reached. Not an approximation and not a wrong number: no output at all, on exactly the shape every judged program has — exit 0 at the end is how the trailing () is suppressed (Q-136). The meter was checked on programs that fall off the end and those all worked._

_Reported from the exit event instead, which fires for process.exit as well as for a normal return. The LLVM backend reached the same conclusion two days earlier with atexit; Wasm was the one that did not have it._ _test/allocmeter/exits.mere pins it, and the gate compares the number against the same work written without the exit — silence would otherwise read as a program that allocates nothing._

_And then the meter was used for what it was built for. Q-138 existed so that Q-135 — 24 bytes per saturated application, fixed for C in v0.1.481-482 — could be asked of the other backends. The answer, measured rather than assumed:_

_The fix was C-only, which the changelog for v0.1.481-482 could not have said at the time because nothing could measure it. And the first row says the problem there is wider than Q-135: that row is zero on C by construction — a named top-level function at a concrete type, applied saturated, written out at the call site — and it costs 16 and 32 bytes on the others. On those backends it is not abstraction that allocates; it is the two-argument call._

_No change to those backends here. The instrument now exists and has been read; what it found is written down in the project's open questions, and fixing it is its own slice._

v0.1.489 — 2026-09-20

_The compiled backtrace is withdrawn: it answered on macOS and said nothing on Linux._

_v0.1.486 printed the frames under a compiled failure itself, reading them back from backtrace() + dladdr. Every gate was green — on macOS. CI is where it broke, and the interpreter half (five cases, position and frames) passed there untouched:_

runtime_loc: 5/5 ok (position + frames on every case)
  compiled frames: got [] want [a__direct b__direct c__direct d__direct]

_`dladdr` consults the DYNAMIC symbol table on glibc, and the frames a Mere program actually stands on are its __direct twins, which are emitted static. A static function has no entry in .dynsym — -rdynamic exports globals and does not change that. Measured in the CI image with a four-frame probe: plain link resolves nothing, -rdynamic resolves mu_a, mu_b and main, and mu_a__direct resolves under neither. So the design could not have worked there; it was not a flag away._

_The retraction rather than a platform carve-out: a diagnostic that answers on one platform and is silent on the other is worse than one that is silent on both, because the silence reads as "nothing to say" instead of "this does not work here". The compiled leg of the gate now pins the SAMENESS — stderr is the message and one newline, byte-identical at -O0 and -O2 — and MERE_FAIL_TRAP=1 is the way to the frames, handed to a debugger whose unwinder reads DWARF and can see a static function._

_The interpreter side is untouched and is where this mattered: the position and the call stack, which is what a 30,000-line file needed._

_⚠ The gate was run on macOS only before it was pushed. The repo already knows to run a new gate once on the CI image — ocaml/opam:ubuntu-24.04 builds mere.exe in about 33 seconds — and that step was skipped. "Tested" is true about the machine it was tested on._

_suite 2773, parity 178, and the three gates plus their poisons green on both macOS and the CI image._

v0.1.488 — 2026-09-20

_Q-138: the allocation meter, on the other two backends._

_`MERE_REGION_STATS` existed in `codegen_c.ml` and nowhere else, so "this change cut allocation" was a sentence only one backend could be asked about. Q-135 — 24 bytes per saturated application, v0.1.481-482 — was verified on C alone for exactly that reason, and the other three were taken on trust._

_Three implementations now answer, and they agree to within 18 bytes. The same program (a 20,000-element Vec, no region block):_

_Wasm counts on the way DOWN. $__lang_bump goes up at an allocation — twenty-odd sites — and down at exactly one, the region release. Instrumenting the one place that goes down is a ninth of the work and avoids writing one rule in twenty places. The total handed out is the bump plus everything a release took back, which also means the bump alone is a lower bound — the reason the second number has to exist._

_And that second number is one the C backend does not have: its regions free whole blocks and never report how much was in them. On the region version of the same program, 99% of 524,306 B goes back._

_⚠ The first number this meter produced was 34 bytes, for a program that allocates 262,194. The release subtracted from mark — where the block STARTED — instead of from the bump as it stood. mark is below the release target, so the difference clamped to zero every time. One name, two questions. It was visible as wrong only because C had already answered for the same program, which is the argument for building the third meter rather than trusting the first._

_LLVM needed both exits of its one allocation function, as the investigation predicted: instrumenting only the path that reads like the main one would undercount exactly the programs that allocate enough to need a second block. In-place growth moves the top pointer without going through the allocator and needs its own line. getenv moved to the unconditional declarations, because env_var_runtime_llvm is emitted only when the program calls env_var and two conditional declarations of one symbol in one module is an IR error — the only program that would have shown it reads an environment variable AND is measured._

_Opt-in through MERE_REGION_STATS, one line on stderr, stdout byte-identical with it on or off. The cost on Wasm is hello.wasm 1,946 → 1,970 B (+24 B, +1.2%, against a band of 1,751-2,141). RV32I stays out of scope: --bare has no stderr._

_scripts/alloc_meter_check.sh is the gate — three-way agreement, the identity alloc_total = live + reclaimed, silence by default measured in BYTES, and twice the work reporting twice the bytes (a meter stuck on a constant passes everything else). Two poisons: the agreement band pointed at the pair that legitimately differs by 2x, and the doubling band pointed at one program against itself._

_parity 178, suite 2773, wasm_size_check 15 files all in band._

v0.1.487 — 2026-09-20

_Which arms no value reaches._

_The other side of the question this compiler has asked since Phase 1. Exhaustiveness says which values no arm answers for. Nothing said which arms no value reaches, and a duplicated constructor arm went through mere, mere check and mere check -c in silence:_

| Rock -> "r" | Paper -> "p" | Rock -> "r2" | _ -> "x" | Scissors -> "s"

_— accepted, exit 0, nothing printed. Two arms there are dead. The defect this answers is a recorded one: when a second arm for one constructor never runs, what the reader eventually sees is an error raised from the arm they did NOT write the code in, and there is nothing in the build to connect the two._

_Exhaustive.redundant_findings already had everything it needed — the arms in order, with their positions. An arm is reported when every alternative it offers was already closed by an earlier UNGUARDED arm, closed meaning an irrefutable pattern, a bare constructor, a constructor whose payload pattern is itself irrefutable, or a literal._

_Only when certain, because the cost of a false positive is a deleted live arm. Four shapes are left alone, and all four are asserted as silent in the suite and in the gate: a guarded arm above the same constructor (a guard can be false, so the arm below it is the one that answers), a constructor with a refutable payload (Link (0, _) is some Links, not all), an or-pattern only half of which is closed (Paper | Scissors under a Paper is still reached by Scissors), and the defensive _ written after every constructor is already named — dead, reportable, and deliberately not reported, because it is the shape people write so a match keeps compiling when the type gains a case, and the noise would bury the findings that matter._

_A warning, not an error. It is a check being added to trees that already compile. Escalating is a separate decision, to be made when the count is zero and stays there._

_It found nothing. 836 sources here, plus mere-ruby's main.mere (30,392 lines and seven modules), m3d and mbrowse: zero dead arms. That is a measured zero and not a blind one — a Nil arm duplicated inside m_strutil.mere, which main.mere reaches through an import, is reported with its file, line and column, so the check does run over a program that size and through its imports._

_scripts/unreachable_arm_check.sh is the gate: seven cases (three reported, four silent), then a sweep asserting the shipped tree stays clean, and a --poison that raises one case's expected count and moves another's expected LINE, requiring exactly one red each. The line half matters on its own — a check that warns about the wrong arm is the failure that costs the most, and a count alone cannot see it._

_suite 2773._

v0.1.486 — 2026-09-20

_A runtime failure says where it happened, and how the program got there._

_Static errors in this compiler have carried a position and a code frame for years; runtime ones carried neither. map_get: key not found in Map was the entire report. In mere-ruby's main.mere — 30,392 lines — that names nothing, and the first thing anyone did with it was go looking for which of the callers reached it._

_Three parts, and the materials for all three were already here._

_The position comes from the application node. The fifty-odd builtins that raise do it with Loc.dummy, because a builtin is handed no position; the App case lends the call site's one to any Eval_error that arrives without one. A builtin that called back into user code (vec_sort's comparator, map_iter's block) re-raises a failure that already knows a better line, and that one is left alone._

eval error: map_get: key not found in Map (use map_has to check first)
  --> lookup.mere:7:29
  |
6 | let m = map_new ();
7 | let lookup = fn (k: str) -> map_get m k;
  |                             ^^^^^^^ map_get: key not found in Map
8 | let go = fn (n: int) -> lookup "missing";

call stack (innermost first):
  lookup at lookup.mere:8:25
  go at lookup.mere:9:8

_The frames are the interpreter's own call stack. Frames are popped on the way BACK and deliberately not on the way OUT, so an unwinding failure leaves them standing for the driver to read — the bargain call_depth right beside it already makes. The first version took a snapshot in an exception handler on every call instead: fib 32 ran 0.66 s with that handler and 0.62 s without, against 0.62 s for the build with none of this. The handler, not the frame and not the allocation, was the whole cost. A frame is the application node, not a (name, position) pair, so a call costs one cons cell and no walk down the spine for a name only a printed frame ever needs._

_⚠ The symmetric-looking version of that is wrong. Restoring call_depth per frame on the way out — the obvious counterpart to the success path — makes the suite fail on the spawn tests, because `call_depth` is one global shared by every domain. A child domain running its own closures writes the same counter, so a main-domain unwind that also writes it lands between the child's +1 and -1. Measured drift: 0 → 1 → 59, and it stuck there for every later program in the process._

_The compiled backend gets the frames from the machine, through dladdr. It works because a user's Mere function is emitted with external linkage (mu_lookup) while the prelude's helpers are static, so the filter is the program's own functions with no list to maintain._

_⚠ A return address is never a function's first instruction, so a pc that resolves to offset 0 is not a frame — it is a pc the walk could not place being handed the nearest symbol that starts there. Without that rule the report named a real function in the program that was not on the path to the failure. Measured on a four-deep chain: at -O0 one spurious +0 frame, and dropping it leaves exactly the chain; at -O2 every remaining frame is +0, and dropping them leaves none — which is the truth, because inlining and tail calls mean those frames are not on the stack to be found._

_MERE_FAIL_TRAP=1 raises SIGTRAP at an uncaught failure instead of exiting, so a debugger holds the program AT the failure with -g mapping it back to the .mere line. Opt-in, because without a debugger attached SIGTRAP is fatal and the exit status stops being 1. A caught fail is control flow and does none of this: silent, no frames, no trap, exit 0._

_MERE_BACKTRACE=0 turns the frames off on both backends; MERE_BACKTRACE_FRAMES caps them (default 10). Runaway recursion arrives with as many frames as the depth limit allows, so repeats are collapsed — down at f.mere:8:35 (x 39)._

_scripts/runtime_loc_check.sh is the gate, and it carries its own poison (--poison): it switches the frames off and requires every case that declares frames to go red, then moves one expected position by a column and requires exactly that case to go red, with the clean run asserted green first so that "red" means the poison and not a broken harness. Both run in CI. Five interpreter cases plus a compiled leg (frames at -O0, none at -O2, both switches, and a caught fail that stays silent with the trap armed)._

_parity 178 unchanged, suite 2767._

v0.1.485 — 2026-09-15

_str_of_int stops going through printf._

_`show_int` was `asprintf("%lld")` followed by `__lang_str_of_cstr` and a `free` -- the whole printf formatting machinery, a malloc, then a strlen, a REGION allocation and a memcpy, and finally a free: two allocations and a copy to spell a number. It writes the digits into a 24-byte stack buffer and makes one region allocation now._

_Measured in C alone, 2,000,000 conversions: asprintf 135-145 ms, digits by hand 52-54 ms. In mere-ruby, where anything that keys a table by an id calls it:_

_Three runs each for the first two, five for the last -- which is the honest one to read carefully: its ranges nearly touch, so call it 2-3% and not more. The CSV row is 23%._

_⚠ The input that breaks a hand-rolled itoa is the most negative integer, where -v overflows -- and signed overflow is UB the optimiser may delete a guard for. The form here computes (unsigned long long)(-(v + 1)) + 1 and never negates the value at all. Two tests pin it: the minimum, and the zero / negative / maximum trio._

_Checked on the interpreter, the C backend and LLVM -- eleven lines each, identical, edges included -- and the emitted C was compiled and run on the Linux CI image for the same answer. (LLVM has its own show_int through mint_show_format and is untouched; it agrees because it always did.)_

_2767 tests, parity 178/178._

v0.1.484 — 2026-09-14

_The underscore that was worth 100x._

_`try_or` compiles to `_setjmp` / `_longjmp` instead of `setjmp` / `longjmp`. On macOS and the BSDs the plain pair SAVES AND RESTORES THE SIGNAL MASK, and that is a sigprocmask syscall on every entry. Measured here with a three-line C program, 3,000,000 iterations:_

_~100x, and it is paid on ENTRY -- not on the rare unwind. Anything that wraps a call in try_or pays it per call. In mere-ruby, an interpreter written in Mere, try_or is entered once per Ruby method call, and the plain pair was 7% of the whole profile (225 of 3,305 samples, with sigprocmask and __sigaltstack sitting under it)._

_Three runs each, no overlap between the two sets._

_Nothing depends on the mask being restored. The runtime never blocks a signal, and no signal handler longjmps out -- the SIGSEGV handler writes one line and _exits. On glibc setjmp already does not save the mask, so this changes nothing on Linux; the emitted C was compiled and run on the CI image to confirm _setjmp is declared there too (same answer, clean build)._

_Both backends that emit it: the C one (4 sites) and the LLVM one (declare i32 @_setjmp(ptr) returns_twice, and the _longjmp call in the fail path). A try_or program gives the same answer on the interpreter, the C backend and LLVM._

_A test refuses the plain pair, because dropping the underscore is a 100x regression on one platform and invisible on the other -- exactly the kind of change no ordinary test notices. It emits C for a try_or program and fails if a bare setjmp( or longjmp( appears; poisoned by putting one back, and it went red._

_2765 tests, parity 178/178._

v0.1.483 — 2026-09-14

_A name can be promised before it is defined._

_`let fn <name>: <type>;` declares a top-level name ahead of its definition, so two functions can call each other without sharing one let rec ... and ... chain. The chain was the only tool for mutual recursion, and it is also the unit of MONOMORPHISM: everything inside one is instantiated at a single type. So in a large program "these two call each other" and "these two must have the same type" were one statement, with no way to say only the first._

let fn even: int -> bool;
let odd  = fn (n: int) -> if n == 0 then false else even (n - 1);
let even = fn (n: int) -> if n == 0 then true  else odd  (n - 1);

_A declaration is checked, not trusted. The definition is unified against the declared type where it appears, and a promise still unkept at the end of the program is an error naming the declaration's line._

_mere --decls <file> prints the declarations for a program's own top-level names, so an existing chain can be cut without transcribing types by hand._

_The feature landed with four defects, and its seven unit tests were green for all four. Every one of them needed a real program to see, and what saw them was pasting --decls output back into the file it came from and requiring byte-identical output — now scripts/decls_roundtrip.sh, over the 178-program parity corpus. It found:_

_The first is uniquify_toplevel_shadows, which renames a top-level binding that shadows a builtin and did not know about forward declarations: the promise kept the name odd and the definition became odd__v2, so the promise was registered under one name and kept under another. A declaration and its definition are one binding, so the rename happens at the declaration now and the definition inherits it._

_The second and third are one root: the declaration and the definition were related by INSTANTIATION rather than SUBSUMPTION. Unifying the definition against a fresh instance of the declared scheme lets the definition be narrower than the promise, and the instance's variables — made at the outer level — drag the definition's own variables down out of reach of generalize. Unifying against the declaration AS WRITTEN fixes both: the parser makes 'a a TyParam, which unifies only with itself or an unbound variable, and that is exactly a skolem. The declared scheme is then what the name means both above and below its definition, which is the whole point of writing one._

_A fifth thing the round-trip found is not a defect: a declaration for a name that shadows a builtin moves the shadow up to the declaration, so a caller written above the definition stops seeing the builtin. That is the feature working — test/parity/shadow_builtin.mere exists to hold exactly that ordering — but it is not what someone pasting a generated file expects, so --decls prints those lines commented, with the reason. Names bound twice at top level get the same treatment, for a plainer reason: one declaration cannot name two bindings._

_let fn also accepts a module-qualified name (let fn M.f: int -> int;). The lexer makes each . its own token and the parser matched a single identifier, so every module member was undeclarable — 625 of the declarations --decls printed for the corpus._

_167 of the 168 corpus programs round-trip. The one that does not names a record type declared inside a module, which cannot be named in an annotation from outside it at all — let use = fn (r: M.t) -> r.a fails the same way, with no declaration involved. It is exempted BY NAME in the gate, and the gate fails if it ever starts passing, so the exemption cannot outlive its reason._

_The feature came from a program that had outgrown the chain: an interpreter whose let rec eval_e = ... and ... had reached 38,856 lines in one file, because everything reachable from the evaluator had to live in it. Six generated declarations were enough to cut it. That program does not ship the cut — it peeled off everything the chain did not need instead, which is the better answer for that codebase — but the constraint it was working around is gone either way._

_16 tests (2764 total), one new gate. Documented in docs/language-reference.md._

v0.1.482 — 2026-09-14

_And the lambda written at the call site._

_An anonymous closure gets an uncurried twin too. v0.1.481 gave named fns and their values an fn2, which left vec_sort v (fn a -> fn b -> a - b) paying an environment per comparison: an anonymous closure had no __direct twin to point at. It has one now, and the generic call path reaches it through a dictionary field as well, so a trait method is no longer the expensive spelling of the same thing._

_Every row of the table this arc started from is zero:_

_The condition for peeling is the one peel_lifted_direct already used, and it is not a detail: the body must be IMMEDIATELY another fn. fn a -> { print a; fn b -> … } does work when it takes its first argument, a program can see whether that happened, and it keeps the two-step path. The cost of the twin is that a two-argument lambda's body is emitted twice._

_The generic path now also accepts a head that is a FIELD rather than a name. A name can be something the arms above call directly with no closure anywhere — that is what broke the first version of this guard — but a field read is already a value, and it is how a trait method arrives._

_`scripts/closure_alloc_pin.sh` pins both directions, and the floor is the one that matters: a partial application must still allocate. A gate that only checked that saturated calls are free would stay green the day the two-step fallback was deleted, and a callback with no fn2 would then call through a null pointer. It was poisoned before being believed — with fn2 disabled it reports 5,034,136 bytes and fails; with it, 8,224 and passes._

_New parity program closure_fn2_order.mere holds the three things a program can see across all four backends: partial application still returns a closure, work between the parameters still happens before the second argument is evaluated, and a comparator is called the same number of times in the same order._

_2748 tests, parity 178 + 18, ctest 18, contrib 79 of 87._

v0.1.481 — 2026-09-14

_The uncurried twin was already in the file; the value did not carry it._

_A closure whose return type is itself an arrow now carries `fn2`, an entry point taking both arguments at once. Applying a curried closure to two arguments used to build the intermediate closure's environment just to pass the second one: 24 bytes and about 13 ns, on every spelling that abstracts over the function. On a 200,000-point sort that was 1,855,936 environments and 60.4% of everything the program allocated._

_What the search turned up is that half the fix was already emitted. A named top-level fn gets a __direct twin, and for the sort in question mu_cmp__direct(P, P) and mu_cmp_as_value were in the same file — the value simply did not point at the twin. Same shape as Q-066 (v0.1.325), where the twin had been emitted for years and the call site looked it up under a name it was never keyed by._

_fn2 is NULL wherever a twin cannot be named — a polymorphic callee, a twin that takes leading region parameters, an anonymous lambda (which has no twin at all yet) — and the two-step path is still emitted right below it. That is the fallback, and both codegen assertions were written to keep BOTH paths in the text: a test that only saw the fast path would go quiet the day the fallback was dropped._

_Two things had to be narrowed after they broke something. The first guard checked only the TYPE of the call's head, so an inner-lifted fn — which the arm below calls directly, with no closure anywhere — was turned into a compound literal of a closure typedef the program had never needed and therefore never emitted. The C did not compile. scripts/parity.sh caught it, by failing to BUILD rather than by answering wrong, which is the cheaper of the two ways to find out. The head must be a local holding a closure._

_The second is evaluation order. A curried closure with no fn2 may do work when it takes its first argument, and the program can see the order, so the partial application still happens before the second argument is evaluated. The emitted shape is awkward on purpose: the inner closure is declared without evaluating the call (__typeof__), assigned only on the slow path, and the second argument appears once. fn2 exists only for a callee that does nothing between its two parameters, so skipping the step there is unobservable._

_Only arrow-returning closure structs grow, by one pointer: unit -> unit (spawn's) and str -> unit (a Logger field) are untouched. 2748 tests, parity 177 + 18, ctest 18._

v0.1.480 — 2026-09-14

_The output was already assembled, and building it bought nothing._

_`print_no_nl` and `print_bytes` hand the whole buffer to one `write(2)` instead of fwrite-ing it onto stdio. main sets stdout line buffered, which is right for a program someone is watching -- a server's log should not stop existing because it was redirected -- and wrong for one that has already finished its answer: an fwrite of a 15 MB buffer onto an _IOLBF stream flushes at every newline. So the idiom the docs recommend, accumulate into a StrBuf and print once, still paid one syscall per line._

_Measured against a judge's test data, twelve programs, worst case each:_

_The constant that disappeared was about 1.6 microseconds per output line, and it was the same number in all ten programs that print more than one line -- 1.50 to 1.99 µs, median 1.6. The two whose answer is a single line did not move, which is how the attribution was confirmed rather than assumed: a fix that also changed the control would have been measuring something else._

_fflush(stdout) leads, because print still goes through stdio and both share fd 1: the order has to be the program's, not the buffer's. A short write is a loop and EINTR is a retry -- dropping the tail of an answer is the one failure mode worth writing three lines to prevent. print is unchanged and still writes a line at a time, which is what a log wants._

_The two codegen assertions this moved were updated to assert the same property they always did: that the LENGTH crosses the boundary, so a zero byte in the middle of a bytes does not end the output._

v0.1.479 — 2026-09-13

_A 13x search, found by pointing a benchmark at an editor rather than at the compiler._

_`str_index_of` compared the needle at every offset. For a needle that is not in the haystack that is one memcmp call per byte of haystack, which is the case a user waits through: "search the whole file and find nothing". memchr finds the candidate first bytes and memcmp only confirms them, which hands the scanning to the one libc function that is certainly vectorised. Measured over a 1 GB file (medit2/bench/big.sh, which is what asked):_

_memchr and not strchr: a Mere string carries its length and may hold NUL bytes, so stopping at the first one cuts the haystack short._

_The search window is derived from last — the final offset a needle can start at — rather than kept in a counter alongside the pointer. A counter that drifts reads past the end of the haystack WITHOUT CHANGING THE ANSWER, because the extra candidates all fail the comparison; that bug is invisible to a differential test and invisible to AddressSanitizer too, since these strings live inside a region arena and the over-read lands in a block ASAN considers live. The possibility is removed rather than tested for._

_test/ctests/str_index_of_scan.mere is new, and is the first behavioural test this helper has ever had on a compiled backend: every existing one went through Pipeline.process (the interpreter) plus an assert_contains that the emitted C mentions the helper's name._

_`scripts/ctest.sh` identified its subjects by basename. With the default set — one flat directory — a basename is unique and this never mattered. Pointed at contrib/, five basenames appear in two libraries each (ast, build, gen, parser, path): FAIL gen named two different files and their temp files collided on one path. Labels are now <dir>/<stem>._

_Two gates are new, both of them turning something that was written down into something that is asked every run:_

_`scripts/contrib_ctest.sh` runs every contrib library's self-tests on the compiled backend and diffs against the interpreter — 79 of 87 pass, 8 pinned with reasons (7 refused by Wasm emission, 1 where the INTERPRETER overflows its stack and the native binary completes). This is the gate that was missing when contrib/toml spent the project's whole history unable to produce C that compiles. The subject list is explicit and its length is asserted, because a glob that skips what will not compile reports green over a set that shrank._

_`scripts/alloc_region_pin.sh` pins both directions of the trade an allocation makes when it is not visible in a function's type: it falls back to the program-lifetime region, which is conservative and correct and not free. The direction nobody intends to change is pinned too — region changes have shipped three versions of this compiler that segfaulted a 3D viewer on its second frame._

v0.1.478 — 2026-09-13

_Six things the medit2 dogfood found by finishing the editor — and four of them were in code no program had used before._

_`mere lsp` was answering in BYTES where the protocol counts UTF-16 code units. They agree on ASCII and on nothing else, and every test this server had was ASCII, so the whole class was invisible. One line with three kanji on it puts the question six columns to the left, and the server answers about the token it finds there — correctly, and about the wrong thing, with no error anywhere. Converted in both directions: incoming positions become byte columns against the buffer the server is holding, and every outgoing range, diagnostic and semantic token converts back. The token LENGTH converts too, or one kanji gets three columns of highlight. Two discriminating inputs are needed and neither substitutes for the other: kanji separate bytes from characters, an astral character separates characters from UTF-16 units._

_Completion could not offer a builtin. Query.completions_at walks the tree for what is in scope, and str_len and print are not declarations, so typing str_l and asking for a completion offered list_iter. Query.builtin_bindings reads Typer.initial_env; they go last, so a name the file defines still shadows them._

_`tty_raw` was not clearing IEXTEN — the same bug as v0.1.476's IXON, one letter along, found the same way: by binding a key to it. IEXTEN enables VDISCARD (Ctrl-O on BSD and macOS), which eats the byte AND throws away the program's next output, so the symptom is "the key did nothing and the screen froze". ICANON, ECHO and IEXTEN are now cleared together because the reason is one reason; ISIG stays with tty_no_signal_keys, because taking Ctrl-C away is a trade rather than a fix, and both sides are pinned in scripts/tty_raw_check.sh (now six checks)._

_A local `let` bound to a polymorphic VALUE was defaulting to int. let init = ("", Nil) in ... list_fold lines init step emitted a tuple_str_list_int and handed it to a function wanting a list of pairs. The v0.1.99 pass that fixes this for local polymorphic FUNCTIONS looked for uses whose type is a concrete ARROW, and a tuple is not one, so values fell through to the defaulting. `contrib/toml` is written this way and has never compiled on any compiled backend — its self-tests run under the interpreter, which has no such type to get wrong._

_`extern fn ... -> str` was broken. This backend's strings carry a length header before byte 0; a foreign function returns a bare char* that has none, so ++ read whatever preceded the constant as the length:_

extern fn getenv: str -> str;
print ("[" ++ getenv "HOME" ++ "]")     =>  out of memory

_The declaration was right and a comment said the difference was "absorbed by the implicit const conversion" — const was the only part of it that was absorbed. The adoption helper already existed and its own comment named getenv as a caller; the extern path was the one place that did not call it. Fixed on both call shapes (direct, and through the _as_value closure), with NULL — an unset variable — becoming the empty string rather than a crash. contrib/log reads LOG_LEVEL this way and could not be built natively either._

_`now_ms` had no interpreter mock, so any program with a timeout in it was compile-only._

_And one feature, because the editor could not use what was there: semantic tokens now carry keyword, string, number and comment, from the compiler's own lexer, merged with the four name kinds from the tree. An editor that coloured the identifiers and left let and the comments plain does not look like it is highlighting anything, and the alternative was a second lexer in every client. Operators and interpolated-string literals are deliberately left uncoloured: the lexer rewrites an interpolation into several tokens that all claim the literal's own position and width._

_Measured while fixing the toml bug: of the 87 extern-free contrib libraries, 79 compile and agree with the interpreter, 7 fail only at Wasm emission, and one "mismatch" is the interpreter stack-overflowing where the native binary completes. toml was the only genuine C-backend failure._

v0.1.477 — 2026-09-13

_Two CI failures from the last two slices, and the reason both were invisible here: one gate was measuring an allocator rather than the compiler, and one number in the README is not derived from anything._

_region_reclaim's perbigvec legs were comparing peak RSS, which cannot answer the question they asked. "Held but reused" and "freed and re-obtained" have the SAME peak; they differ in what the process is sitting on afterwards. macOS hands large frees back to the OS, so the accumulating case happened to show up as a bigger peak and the gate appeared to work. glibc reuses the block, so the identical binary read flat on Linux and CI went red for a property that was never being measured._

_MERE_REGION_STATS now reports the thing itself — region-stats cache: regions=N retained=B, how many regions are cached and how many bytes they are carrying. A function of the program, not of the allocator. Both directions are pinned with it: under __LANG_REGION_KEEP_MAX a released region KEEPS its grown block (measured: 8,388,608 bytes retained after a 5 MiB value), over it the block goes back and the region re-seeds at 1 MiB (1,048,576). Poisoned in both directions._

_The README's parity count said 176 and test/parity holds 177. first_run_check.sh re-derives it, which is why it was caught; the test count beside it is not derived and was stale too._

_`contrib/unicode/width.mere` is not the first display width in this project, and v0.1.476's entry implied it was. utf8_width has been in the prelude since v0.1.45 and in the stdlib reference all along; the search that missed it looked in contrib/ and in the builtin matrix and never in the prelude. Measuring the two is what settles which to use, so that number is now in both docs: over 17,661 code points they disagree on 2,083 (11.8%) —_

_utf8_width needs no import and is enough for lining up a column of a table, which is what it was written for. The generated table is for when a CURSOR has to land where the glyph ends — an editor, a pager, anything that draws over what it drew before — because there the error does not stay in one cell._

_And the two gates added in v0.1.476 declare their dependencies in the CI toolchain preflight, where this project already asserts them: a gate that skips in CI is a gate that passes without running. width_check needs ruby and reline; tty_raw_check needs the python3 already asserted there. All four gates run green under dash, which is the shell CI uses._

_dune runtest 2737/0, parity 195/195._

v0.1.476 — 2026-09-13

_Six things a text editor asked for, five of them small and one of them embarrassing. The embarrassing one is that raw mode was not delivering the keys a program had asked for, and every test in this project that could have seen it was a pipe._

_`tty_raw` clears IXON. A fix rather than a choice: no full-screen program wants software flow control. With it on, Ctrl-S is XOFF and Ctrl-Q is XON — the line discipline consumes both and the program never sees either byte. The medit dogfood documents Ctrl-S as save and Ctrl-Q as quit; driven under a real pty it drew zero bytes after each, stayed alive, and never wrote its file. It had been unusable in a real terminal since July. Rebuilt against this compiler, with no change to its own source, it saves and quits._

_`tty_no_signal_keys` is a second call and not part of tty_raw, because ISIG is a trade rather than a bug. Clearing it delivers Ctrl-C / Ctrl-Z / Ctrl-\ as bytes, which an editor needs — with ISIG set, Ctrl-Z is SUSP and an undo bound to it silently does nothing — and takes away the interrupt key, which a game that quits on q should keep. Folding it into tty_raw would have taken the escape hatch from every existing TUI to serve the one that asked._

_Neither is visible to a piped test, in either direction: a pipe has no line discipline, so 0x13 and 0x1a both arrive and everything looks finished. `scripts/tty_raw_check.sh` drives a Mere program through a real pty and asks whether the bytes it was sent reached it — including the leg that pins Ctrl-C still interrupting under plain tty_raw, so that trade cannot be quietly reversed later. It is poisoned in both directions._

_`Grapheme.clusters` builds each cluster as a `str` rather than a StrBuf, and the difference is where it lives. A container is allocated in the program-lifetime region when the allocation is not lexically inside the caller's region block — and a library function never is — so a StrBuf per cluster was a StrBuf that was never reclaimed. Two thousand frames of forty lines of Japanese came to 127.8 MB, growing linearly, inside a region block that was doing its job. As a str the same run is 1.6 MB and flat, and faster: 0.45 s against 0.84 s. The StrBuf was not buying anything — a cluster is one to a handful of code points, so the quadratic that concatenation would pay is bounded by the length of one cluster and not of the text. Still agrees with ICU on all 8,509 conformance inputs._

_That made clustering affordable per keystroke, so `Width` now sums over clusters: 👩‍👩‍👦 is 2 columns rather than 6, 🇯🇵 is 2 rather than 4, and nothing else moves. Width.of_cp is still the per-code-point answer, which is what a table comparison wants._

_`\}` is a literal brace. A } in a string never needed an escape — only { starts an interpolation — so \} was "unknown escape", and a brace PAIR had to be written with its two halves spelled differently: "\{\"id\":1}". This project's own test suite is written around it. The unescaped form still works._

_An `extern fn` for a name this compiler implements is checked for arity. It was not before: the declaration was taken at face value, the call emitted with that many arguments, and clang reported too few arguments to function call, expected 3, have 2 about a line of generated C — the user's mistake, named somewhere the user did not write. The expected arity is derived by scanning the C this backend emits rather than listed beside it, so it cannot drift from the runtime. Arity only: comparing types needs a compatibility notion that does not exist here, since tcp_close : int -> unit is what every contrib declares and the runtime returns int. Swept over 400 .mere files in this tree: zero false positives._

_A match's unreachable fall-through is cast to the match's type. The placeholder was a bare 0, and a statement expression is typed by its last expression — so ({ ...; 0; }) is an int, and putting that in the else-arm of a conditional whose other arm is a pointer made clang warn on every match over a user variant. Nothing was broken (__lang_fail_impl is noreturn, so the value is unreachable) but a warning that fires on correct code on every build is one nobody reads, and it stops a -Werror build dead. The medit2 dogfood's emitted C carried eleven._

_Measured and not done: incremental LSP sync. mere lsp advertises textDocumentSync: 1, so every change sends the whole buffer, and the obvious next step was 2. The measurement says no. Per-change time against file size, median of five, didChange to publishDiagnostics:_

_Linear, not quadratic. And incremental sync would reduce the bytes SENT while the server still re-checks the whole buffer — 80 KB over a socketpair is under a tenth of a millisecond against 27 ms of checking. It would buy almost nothing; what costs is the check, and that is a different piece of work._

_dune runtest 2737/0, parity 195/195, and every gate above._

v0.1.475 — 2026-09-12

_A positioned read that builds a bytes, the region a positioned read lives in, and what a region hands back when it is released. All three came out of one dogfood — a text editor that opens files it cannot hold in memory — and the third one is the one nobody had measured._

_`file_pread_bytes : File -> int -> int -> bytes`, on all four backends. The read half of file_pwrite_bytes, which has existed since v0.1.222; only the write side had a bytes version. file_pread returns Vec[R, int] -- eight bytes per byte, built one fgetc at a time -- which is what mbtree wants for a page it is about to index as numbers, and not what a reader streaming a file wants. Measured on 208 MB in 256 KiB pages, C backend: 3.64 s at 10.1 MB peak RSS becomes 0.36 s at 1.8 MB. Ten times faster and a fifth of the memory, and it removes a choice: before it, read_bytes was 0.33 s at 210 MB, so paging a file meant picking between memory and speed._

_On Wasm this is the cheap one: the host import already HANDS BACK a bytes pointer and file_pread adds a vec_of_bytes after it, so the new builtin is the same call with the conversion removed._

_`file_pread` was the last container constructor missing from the typer's region-marker list. vec_new, read_file_bytes, strbuf_new, map_new, bytebuf_new and the rest bind their result to the region open at the call site; file_pread's region-quantified scheme instantiated a fresh marker that nothing unified with the block around it, and it settled on the default region. A region R { let v = file_pread f off len in .. } paging through a file retained every page it had read -- 200 pages of 64 KiB came to 107 MB, linear in the iteration count, inside a block that was acquiring and releasing correctly. Writing (file_pread f off len : Vec[R, int]) bound it by hand and cut it to 2.0 MB; it now needs no annotation. The identical hole, with the identical cause, is written up in this file for bytebuf_new (Q-127 / m3d Q-10) -- it survived in the one constructor that gets called in a loop._

_A released region keeps its largest block. This is the one that had to be measured rather than read, and the reason is that the bookkeeping was already right. Releasing a grown region freed its whole chain and re-seeded at 1 MiB; every block WAS freed, and an instrumented run agreed -- 40 releases, 40 chain frees, 40 of 40. The process grew anyway, because the next iteration asks the allocator for those megabytes again and malloc does not hand the same pages back. Forty iterations of a 5 MiB Vec inside a region block reached 216 MB of resident memory. Keeping the largest block and dropping the rest reuses the same memory: 13.7 MB, flat._

_Across the sweep that found it (20 iterations, by the size of the Vec's data):_

_Resident memory now scales with ONE iteration rather than with the iteration count. The 4 MiB row is the cost: a region that grew no longer shrinks back to 1 MiB. The retained block is capped (__LANG_REGION_KEEP_MAX, 16 MiB), because a program that builds one enormous value in a region and then stops using regions should not hold it for the rest of the run -- eight regions are cached per thread, so an uncapped keep is eight times the largest value the program ever built. scripts/region_reclaim_check.sh pins both directions: under the cap the footprint must not follow the iteration count, over it it must. A trade with one side measured drifts._

_io_poll_new / add / mod / del / wait / get and io_set_nonblocking are documented (v0.1.313, stdlib-reference until now only in the changelog). They are poll(2) over a registered interest set and take ANY fd -- fd 0, or a socketpair to a child process from a shim of your own -- which is what lets one loop wait on the keyboard and a subprocess with no busy-wait and no second thread. The dogfood that found this had designed a busy-polling loop around stdin_byte first. Same shape as file_pwrite_bytes, which the mraft dogfood missed for a whole slice for the same reason._

_dune runtest 2733/0, parity 195/195, region_reclaim 11 checks._

v0.1.474 — 2026-09-10

A type name declared twice with different constructors is refused. This is the last item the exhaustiveness arc left open, and investigating it moved it out of the language's DEFERRED list entirely: it is not a module problem and it does not need module types namespaced.

What was measured first, because the framing decided the size of the change:

type t = A | B;
type t = X | Y;
match A with | A -> 1 | B -> 2      // exit 0, answers 1

Both declarations are accepted, the SECOND wins for the name t, and the FIRST's constructors stay usable — they are keyed by constructor name, not by type. So the compiler holds one model for two types, and everything downstream answers from whichever came last: a match over the first type is checked against the second's cases, == compares values of two types as one, and a function annotated with the name accepts either. All three were measured, at top level and inside modules, and they behave the same. Module types are registered globally and unqualified on purpose — the parser drops the prefix from a qualified annotation, and says so — which is why module A { type t } beside module B { type t } is exactly the top-level collision and not a scoping bug. DEFERRED §4.1 (namespacing module types) is a different and larger change that this does not need.

Restating a type identically stays fine, because it is ordinary here: twelve files in this tree restate 'a list or 'a opt for self-containment, and both declarations describe the same type. Only a CONFLICTING redeclaration is refused, with both constructor sets in the message and a help: that says which half is allowed.

The count, measured before it became an error

Zero conflicting redeclarations across 945 files here and six downstream repositories. Fifteen type names are declared with different shapes across the ecosystem — tree in three shapes across ten files, expr in four — but each shape is a different program, and the registries are per-compilation, so none of them is a collision. The refusal cost nothing.

Which is how it found a real bug of its own

The first sweep reported conflicts that were not there: a type shape in one test program read as a prior declaration of the type shape in the next. `Exhaustive`'s three registries were never cleared between compilations. Typer.reset_type_registries has restored the typer's own tables per program since v0.1.291 for exactly this reason, and the checker's were not in it — so a process that compiles more than one program (the test binary, and the language server on every keystroke) could consult the previous program's constructor list for a type the current one does not declare. They are cleared now.

What this closes

test_basic.ml carried a row asserting today's wrong answer for the half the exhaustiveness checker could not decline — a subset collision (X | Y beside X | Y | Z), where every arm is found in the entry and the extra constructor is reported as missing. That program is refused at its declaration now, before any match is looked at, and the row is a refusal test. The checker's entry_describes_column decline stays as a backstop; the cause it guarded against cannot reach it.

Two modules may still share a CONSTRUCTOR name (Traffic.Red and Mood.Red), which is what module scoping is for and has its own test beside this one.

Unit 2733/0, parity 194/0, exhaustive_check 31, check_cmd_check 883, refusal verified on all five paths.

v0.1.473 — 2026-09-10

The four real holes are fixed, and a nested missing case is an error. v0.1.472 shipped the usefulness algorithm with its new findings as warnings and called that a migration switch. Measuring is what made a better line available: the whole ecosystem had four holes, they were all the same one, and fixing them took four lines.

All four are the same idiom — reading an optional second command-line argument:

let live = match argv with | Cons (_, Cons (b, _)) -> int_of_str b | Nil -> 2000;

With exactly ONE argument neither arm matches. The default is what an absent second argument means, and one argument is as absent as none, so the arm is | _ ->. Two benchmarks (churn/bench.mere, churn/bench_regionloop.mere) and two region-reclaim tests. benchmarks/churn/MANIFEST passes two arguments always, so the measured path is unchanged; what changed is that the one-argument invocation now returns the default instead of falling through.

The line, which is now a property rather than a phase

Not "what the old checker could express". Two classes of witness, and they differ in kind:

The second row's only fix is the catch-all the language reference already asks for at every match over a scalar, so refusing the program adds nothing the warning did not say. The first row's finding carries information the person did not have. witness_has_open_literal is the whole predicate.

It also keeps test/parity/nonexhaustive_caught.mere and its fail/ twin compiling, which matters more than it sounds: they hold the RUNTIME behaviour of a fallthrough, and if every named miss were refused, no compiling program could reach one. The per-file flag hook scripts/parity.sh would have needed is not needed.

After both

Zero findings of either severity across 838 files here and 118 across sixteen downstream repositories, mere-ruby's 51,000 lines included. The promotion cost nothing because the measurement came first.

Unit 2732/0, parity 194/0, exhaustive_check 31, check_cmd_check 883, bench_check and region_reclaim_check green on the four edited files.

v0.1.472 — 2026-09-10

The exhaustiveness check looks inside patterns now. It compared TOP-LEVEL constructors, which answers the common question and is blind to a whole class: | Cons (TId nm, r) and | Cons (TP lp, r) between them "cover" Cons, so a third token kind in that position was never reported. What replaces the four hand-written branches is the standard usefulness algorithm (Maranget), which this pattern language fits without ceremony — no ranges, no array patterns, no lazy patterns, a constructor carries at most one sub-pattern.

Exhaustiveness is usefulness of an all-wildcard row against the matrix of arms, and asking it that way produces a witness: an actual value the match does not handle. The message prints the witness and the help: arm is built from it, so the arm comes out of the same computation that found the problem instead of being assembled next to it.

warning: non-exhaustive match (missing Cons (_, Nil))
  = help: | Cons (a1, Nil) -> ...

That is this repository's own benchmarks/churn/bench.mere: an arm for two arguments, an arm for none, and nothing for one.

The count, and a correction to v0.1.470's account of it

v0.1.470 reported 269 candidate sites here from a syntactic sweep and said the first two read by hand were both real holes. Running the actual algorithm over the same 838 files finds four — all of them the same one-element-list hole, in two benchmarks and two region-reclaim tests — and every downstream repository clean, mere-ruby's 51,000 lines included. 269 was a loose upper bound on a necessary-but-not-sufficient shape.

And one of the two hand-read sites was a misreading, corrected in that entry: contrib/db/ redis_cluster.mere has a third arm, | Cons (_, rest) ->, that the first pass did not read. Its match is exhaustive. Which is the argument for computing the answer rather than eyeballing the shape — twice over, since the eyeballing is what produced both wrong numbers.

What it can say that the old check could not

• Inside a constructor. | Cons (0, Cons (b, _)) with | Nil is missing more than a

Cons; the witness says which shape.

• A value, where it used to report an absence. match n with | 0 -> … | 1 -> … was

"no wildcard arm for int" and is now missing 2. A str witness is one character longer than the longest the column holds; a tuple with a literal component reads (1, _) instead of (_, _), which claimed the pair the arm does handle.

• Records by declared field, with an omitted field read as a wildcard — both forms are

legal source — and bool and unit as the finite types they are, at any depth.

The arm is not the witness verbatim. A wildcard in the witness is a position the arm should BIND, so the headline reads Triangle (_, _) and the arm reads | Triangle (a1, a2) -> ...; a literal in the witness becomes a binder too, because | 1 -> ... for "missing 1" leaves everything except 1 uncovered, and an arm that is a bare binder prints as | _ -> .... scripts/exhaustive_check.sh pastes the arm back into the program and uses every name it introduces, which is what caught the first version of this printing | Triangle _ -> ....

What stayed the same, deliberately

The error is still a single top-level constructor with an unconstrained payload, which is exactly what v0.1.468 refused. Nested findings and open-signature findings are warnings. That is a migration switch rather than a principle, and it is a property of the witness, so there is no second checker kept around to ask: witness_is_shallow.

Two things it buys. The four real holes can be fixed before the class is promoted. And the two parity cases that hold the RUNTIME behaviour of a fallthrough are compiled by exactly this permission — with a complete checker and no permission, no compiling program can reach a fallthrough, so its behaviour becomes untestable without a flag scripts/parity.sh has no hook for. Promotion is: fix four sites, give the harness a per-file flag, then flip.

The same-named-type guard is generalised to any column rather than the top level. Two modules that each declare type t share one entry in the variant registry, so a match over the first type would be judged against the second's constructors; an arm naming a constructor the entry does not have is the evidence that the entry is about another type, and the match is DECLINED — v0.1.468 chose silence there and it is still the right answer.

The dependencies it needed were two pushes the registry never made: a type's declared parameters, without which a polymorphic payload cannot be instantiated (Some of an int opt is int), and the record field list. Both come from Typer, whose dependency on this file is one-way, so they arrive the way the variant list already did.

The search is bounded at 20000 constructor specialisations and declines rather than hangs.

Unit 2732/0, parity 194/0, exhaustive_check 31, check_cmd_check 883.

v0.1.471 — 2026-09-10

A producer that outruns its consumer past 65536 queued messages succeeds on the interpreter and on C, and died on LLVM with no output at all. Found by sweeping the remaining bare abort() sites after v0.1.470 rather than by hitting it: six were left in the LLVM backend, four of them show / eq_ / cmp_ walking variants they generated the arms for — internal invariants — and two reachable from a program.

let c = channel_new ();
let rec fill = fn (i: int) -> if i > 70000 then i else let _ = channel_send c i in fill (i + 1);

The buffer here is fixed at 65536 slots and its own comment says so. The divergence stays: growing it needs the per-message region array the C channel has and this struct does not, which is a different slice. What is fixed is that it no longer dies mute — the label said oom when the condition is capacity, and abort() took the buffered stdout with it, so a program that had queued 70000 messages printed nothing. Named, exit 1, and catchable, which is what every other refusal in that file already was.

try_or around the fill now returns -1 on LLVM and 70001 on C. Both are legible; one of them used to be a signal.

v0.1.470 — 2026-09-10

A `match` that falls through gave four answers, and the note in v0.1.468 said the wrong thing about all of them. Measured this time, on a program that actually reaches the missing arm rather than one that merely has it:

So the claim v0.1.468 wrote into six places — "each backend invented a value, and the answer came back wrong instead of refused" — was true of exactly one backend. C and LLVM ran a bare abort(), Wasm executed unreachable, and all three failed late and mute rather than wrongly. RV32IM was the one that really did carry on with a value: the arm chain's last mismatch falls straight into the merge label with the saved stack pointer still in a0, so the match evaluated to a stack address and the program used it. Its comment said "typer guarantees exhaustiveness, so some arm matched" — which it does not, because a match over an int with no wildcard arm is a warning and compiles.

Every copy of the wrong sentence is corrected in place, with what measuring found: lib/pipeline.ml, scripts/exhaustive_check.sh, .github/workflows/ci.yml, benchmarks/json/bench.mere, both places in the v0.1.468 entry, and one comment in mere-ruby. The commit messages are history and stay as they are; this entry is the correction they point at.

One answer, on all five paths

Nothing new was written to do it — each backend already had the mechanism, applied to fail and not to this:

• C: __lang_fail_impl("no matching arm in match") in place of abort(). Its own note

explains the choice made for fail: "an uncaught fail is a program error the language defines, not a crash. abort() made the shell report 134 / SIGABRT and could dump core, while the interpreter and the Wasm backend both exited 1 for the same program."

• LLVM: the same helper with a length-prefixed message constant, beside the lb_push

ones. The other @abort() sites in that file are show / eq_ / cmp_ walking variants they generated the arms for, which is a different claim and left alone.

• Wasm: call $__lang_fail, which is what v0.1.275 gave vec_get for the reason

written there — "no message, nothing for try_or to catch, where the interpreter raises a catchable failure". A match that falls through was the remaining one.

• RV32IM: emit_abort, this file's own compile-time-known message, whose comment

records the same lesson a third time: the copy that used to live there was the write-and-exit half only, "which is why every abort this backend emitted was uncatchable".

The message carries no fail: tag, because that tag belongs to the fail builtin and this is the backend's own failure — the convention the other internal failures already follow, and the one scripts/parity.sh's payload() is written around.

Two parity cases, because one shape cannot hold it

test/parity/fail/uncaught_nonexhaustive.mere pins the message and the status across four backends. test/parity/nonexhaustive_caught.mere pins catchability, and it is in the passing corpus rather than fail/ because it succeeds: every backend exits 0 and the answer differs, which the failure section cannot compare. It is also the only one of the two that covers RV32IM, because scripts/rv_exec_check.sh sweeps the passing corpus and the failure section has no RV leg.

Both use an int scrutinee on purpose. Since v0.1.468 a missing case the checker can NAME is a compile error, so a program that reaches a fallthrough is one the compiler refuses — except where the checker admits it cannot name what is missing, which is exactly the scalar case that stays a warning. That decision is what keeps these two files compiling without a flag; if it is ever revisited, they are what says so.

Poisoned three ways. Reverting C to abort() gives c:EXIT(134) on the uncaught case and fails the caught one; reverting Wasm to unreachable gives wasm:OUT. Parity 194/0 (176 + 18), unit 2724/0, exhaustive_check 31, check_cmd_check 883. RV32IM checked on both cases against the C backend under the emulator, which is the comparison rv_exec_check.sh makes.

What is still open, and why it is not here

The checker's blind spot. It compares TOP-LEVEL constructors only, so Cons (TId nm, r) and Cons (TP lp, r) between them "cover" Cons and a third token kind falls through. Swept: 269 such sites in this repository (of 38,088 matches), 162 in mere-ruby, 127 in mbrowse.

v0.1.472 corrected the two sentences that followed. They said the first two sites examined by hand were both real holes. One was — benchmarks/churn/bench.mere has no arm for a one-element argument list. The other was a misreading: contrib/db/redis_cluster.mere has a third arm, | Cons (_, rest) ->, that the first pass did not read, and its match is exhaustive. And 269 was a loose upper bound on a necessary-but-not-sufficient shape: running the real algorithm over the same 838 files finds four, all the same hole, and every downstream repository clean.

Closing it is the standard usefulness algorithm, which this pattern language fits (no ranges, no arrays, no lazy patterns) and which needs two things the registry does not push yet — a type's declared params, to instantiate a polymorphic payload, and the record field types. That is implementable; making it an ERROR is a migration of several hundred sites, so it wants to land as a warning first. This release makes the runtime half honest in the meantime.

Two types with the same bare name. Not a checker bug: module-internal types are registered globally unqualified and the parser drops the Module. prefix from a qualified annotation, on purpose. So Foo.t and Bar.t are the same type — measured three ways: a match over one takes the other's arms, Foo.X == Bar.X is true, and a function annotated Foo.t accepts Bar.Z. The checker is being asked about a type with two conflicting declarations and has no right answer available, which is why it declines (v0.1.468). Fixing it means namespacing module types — DEFERRED §4.1, a breaking change across the parser, three typer registries and four backends — and it is not an exhaustiveness item.

v0.1.469 — 2026-09-10

`mere check <file>` — accept or refuse the program, emit nothing, say nothing when the answer is yes. There was no way to ask that question. The only cheap thing that looked like an answer was mere -t, which runs the declaration loop and NOT the borrow, spawn- capture or exhaustiveness checks — its own help has said so for a while, and examples/borrow_conflict.mere is the standing proof: -t exits 0 on it and every compiled backend refuses it. So the honest way to ask was to compile the program and throw the output away.

On this repository's largest Mere program — mere-ruby, 51,014 lines — that costs:

Codegen is 28 of those 34 seconds, so on a file that size the answer was six times more expensive than the question. On a small file the two are the same 30 ms of process startup: the win is entirely where it is needed and nowhere else.

It runs exactly what the four backends are handed — Pipeline.infer_program: inference over the declarations and over the desugared program, the channel-element Send obligations, the borrow conflicts, the spawn-capture move analysis, and the exhaustiveness findings. Silent on success, because the exit status is the whole interface and a check that prints on the good path cannot go in a loop; that is how mere fmt --check already reads.

The gap it has is stated rather than hidden. Codegen is not run, so a backend that refuses what it was handed is invisible to the bare form — test/parity/bytebuf_edges.mere type-checks and both the LLVM and Wasm emitters refuse it. mere check -c | -ll | -w | -rv runs that backend's emit as well and discards the bytes, which is the only way to ask "will this build" rather than "is this a valid program". The same four flags the compile paths use, rather than a second spelling (--target c) of the same four things.

The gate is a differential, because the hazard is not a bug

What mere check is exposed to is becoming a second -t: a fast answer to a different question. Three hand-picked cases cannot hold that, because the failure would be a program nobody thought to pick. So scripts/check_cmd_check.sh sweeps all 291 files in `examples/` three ways and holds:

• check -c and -c agree exactly — they do the same work and differ only in whether

the bytes are printed, so a disagreement is the subcommand having grown its own opinion;

• check accepts everything -c accepts — a check that refuses what builds sends people

hunting a bug that is in the checker;

• where check accepts and -c refuses, check -c must refuse it too. 13 of the 291

are such rows, so this is exercised rather than vacuous.

Plus the named cases the sweep cannot supply: -t accepts borrow_conflict.mere and check refuses it (if that inverts, the subcommand has become -t); bare check accepts bytebuf_edges.mere while -ll and -w refuse it (without this, the third invariant could pass on a corpus where no backend ever refuses anything); silence on the good path; and the two usage errors.

Three poisons, and one of them found the gate lying. Making check behave like -t is caught by the named row. Making it silently run codegen is caught both by the accepts-what-builds sweep and by the bytebuf_edges row. Dropping its ~quiet:true was caught by nothing: the silence check read $(...), which strips trailing newlines, and check returns the empty string — so printing it produced exactly one newline that command substitution ate. It counts bytes now, and the poison reports wrote 1 byte(s) ... \n. That is the same trap the puts work two commits earlier used od -c to avoid, walked into one file over.

v0.1.468 — 2026-09-10

A `match` missing a case was a warning, and the warning was printed from inside the interpreter's path — so `-c`, `-ll`, `-w` and `-rv` said nothing at all and exited 0. The four backends that produce the artifact were the four that never mentioned it.

type shape = Circle of float | Square of float | Triangle of float * float;   // the edit
let area = fn (s: shape) ->
  match s with
  | Circle r -> 3.14159 * r * r
  | Square w -> w * w;                                                        // untouched

Before: mere shape.mere printed one line of warning above the answer and exited 0; mere -c shape.mere emitted C and exited 0. This is the ordinary edit — a case added to a type, every match over it left as it was — which is exactly why the check has to be on the path the person or the agent is actually using.

v0.1.470 corrected the two sentences that used to be here. They said a fallthrough has no value to return, so each backend filled it in with one of its own and the answer came back wrong instead of refused. Measured, on a program that actually reaches the missing arm: the interpreter names the failure and points at the line, C and LLVM ran a bare abort() (exit 134, no output), Wasm executed unreachable (exit 1, no output), and only RV32IM carried on with a value — the saved stack pointer. So on three of the four the failure was LATE AND MUTE, not wrong. That is a smaller claim than the one written here, and still reason enough to move the check to compile time; the runtime half became one answer on all five paths in v0.1.470.

After, on all five:

error: non-exhaustive match (missing Triangle _)
  --> shape.mere:4:3
  |
3 | let area = fn (s: shape) ->
4 |   match s with
  |   ^^^^^ non-exhaustive match (missing Triangle _)
5 |   | Circle r -> 3.14159 * r * r
  |
  = help: | Triangle (a1, a2) -> ...
  = note: or `| _ -> fail "todo"` to compile before writing them

The arm is the message. The edit that provokes this check is almost always the same one, and the next thing anyone does with the error is write the arm it names — so the error writes it, one help: line per missing case, and then the hole: fail is typed 'a, so | _ -> fail "todo" satisfies any match and the rest of the file keeps compiling while the arms are filled in. One finding per match, not one per case: a match missing seven constructors used to be seven separate lines that had to be read together to discover they were one edit.

What stayed a warning, deliberately. no wildcard arm for int is not promoted. That arm of the checker is an admitted approximation — it fires because the scrutinee's cases are unknown, so it cannot tell a match that is missing one from a match over a type it has no model of, and making it an error would demand | _ -> on every match over a scalar rather than point at anything. The split is exactly "can the checker name the case": if it can, the build stops; if it cannot, it says so and carries on. --allow-nonexhaustive downgrades the errors too, for a tree mid-port.

Warnings now go through the same renderer the errors use, which they did not: a warning was a bare line 4, col 3: warning: ... while a parse error two lines above it got the file, the source line and the caret. And warning is yellow where error is red — they were the same colour, which is how a terminal showing both made them one class of thing.

What promoting it found

Three latent fallthroughs in this repository, and one of them was an arm the parser had given to the wrong `match`. contrib/regex's match_re ends with

  | _ -> match_seq (Cons (pat, Nil)) s 0;

written for match pat with — and parsed as a third arm of the nested match atoms with, which already had a _ arm above it. So the arm was dead code, the outer match had one arm for seven constructors, and match_re (RChar "a") "a" reached a fallthrough instead of the answer written for it four lines below. Parenthesising the inner match is the whole fix; the RSeq path is unchanged and examples/regex_demo.mere still reports all 21 cases ok. benchmarks/json/bench.mere had no arm for JFloat in a walk whose job is to count every node — unreachable for the document the MANIFEST pins, and for any other one an abort with no message (this sentence said "a number invented"; see the correction above).

A false positive that had been hiding behind the warning. Two modules that each declare type t share one entry in the variant registry, because it keys on the bare name — so a complete match over the first type was judged against the second's constructors and told to add Z. Harmless while nobody read the warning; a rejected correct program the moment it became an error. An arm naming a constructor the entry does not have is the evidence that the entry belongs to another type, so the check now declines instead of naming a case out of the wrong declaration. v0.1.284 fixed the other half of this (a qualified constructor M.Leaf normalised to its bare segment); this is the type-name side of the same collision. The half still answered wrongly — one type's constructors a subset of the other's, where every arm is found and the extra one is reported — is a row in test_basic.ml asserting today's wrong answer, so the day the registry is keyed on the qualified name, that check goes red and says where to look.

Outside this repository: four sites in `mere-ruby`, across three files — eval_e has no arm for EKwSplat (the parser builds it in ten places) and parse_x_target1 none for Nil. Each is a Ruby-semantics question rather than a mechanical fix, and each is a silent wrong answer today on all five backends. --allow-nonexhaustive builds all three files meanwhile.

Gate

scripts/exhaustive_check.sh (31 checks). It holds the refusal on interp / C / LLVM / Wasm / RV32IM — the shape of the bug was "one path checks, four do not", so a gate on one path would have been the bug again — and it reads the arm out of the compiler's own output, splices it back into the program, and runs it. A hint nobody can paste is worse than no hint, and a remembered string here would not notice the day the pattern syntax it prints stops parsing: dropping the parens from the tuple-payload arm turns this red with the parse error to prove it. It also carries the negatives — a match with every arm written must build and be silent on all five paths, | _ -> fail "todo" must build and run on the compiled backends too, and a match over an int must not stop a build.

Swept: 838 .mere files here plus 113 across six downstream repositories. With and without --allow-nonexhaustive the mere tree gives the same 769 ok / 69 pre-existing failures, so nothing in it is refused by this change that was not refused before. Unit suite 2724/0.

v0.1.467 — 2026-09-10

A closure written inside a `region` block that calls an inner function which allocates did not compile, on both compiled backends, and had not since v0.1.453. Not "compiled wrongly" — the emitted C and the emitted IR named values that were not there:

error: use of undeclared identifier '__region_SC'      (C)
error: use of undefined value '%v'                     (LLVM)

v0.1.453 gave a lifted inner function its enclosing region as a leading argument, so a body called from a nested block allocates where it was written (Q-131). A closure that CALLS such a function has to carry that argument in its env. The C backend already pulled a lifted callee's captures into the closure's env — and then filtered them by `List.mem_assoc n current_var_types`, which a region name never satisfies, because it is not a variable. The one capture that mattered was the one dropped. The LLVM backend had no such pulling at all, so it lost ordinary captures too.

Three parts, and only the first is obvious:

1. a region capture is not a variable, so it must be let through that filter and typed

as the region marker rather than looked up;

1. the lifted function may be defined inside the closure rather than free in it

(m3d's let rec prims inside its walk callback), so the scan is over every name the body mentions or binds, not over its free variables;

1. a region the body opens must not be captured — one_frame_into contains the

region SC { }, and the curried closure form of it is built at the top level where SC does not exist. Widening the scan without this emitted __env->__region_SC = __region_SC; with nothing to read.

Why it took thirteen versions

It needs all three at once: a region block, a closure written inside it, and an inner function the closure calls that allocates. Nothing in 175 parity programs, 286 examples or 13 downstream repositories had written that. m3d did, the first time it put a block around its frame's working set — which only became worth doing once v0.1.458 and v0.1.464/466 made a block reclaim what a callee allocates. The feature's first real user found the hole its own machinery had left.

test/parity/region_closure_calls_lifted.mere is the shape, in eleven lines. It fails on a build of v0.1.457 with the same message, so this is not something today's region-passing introduced.

parity 175 / 0. dune runtest 2717 / 0. escape 20 routes, 0 holes. 13 downstream repositories type-check. region_reclaim 9 checks, region_params 11.

v0.1.466 — 2026-09-09

The LLVM backend passes the region too, so Q-127's remaining half is closed on both compiled backends.

define ptr @mu_deep__int__Vec_int(ptr %__rp1352, i64 %n)
  call ptr @mu_deep__int__Vec_int(ptr %t6, i64 2)                 inside `region A { }`
  call ptr @mu_deep__int__Vec_int(ptr @__lang_default_region, ..) outside it

Both legs of region_reclaim_check assert FLAT now. Between the two versions the LLVM leg asserted the OLD behaviour and went red the moment it changed, which is how the table got updated instead of quietly rotting — and it is what told me each half had landed.

It is not the same hook, because this backend has no uncurried twin

The C backend hangs the region arguments on __direct, the N-ary form of a curried top-level function. LLVM has no such form: a top-level function is define T @f(P %param), one parameter, and a saturated multi-argument call goes through closures. What it does have is a direct call for the first application, so the region arguments lead there — and the innermost body of a curried function is a separate define that cannot see them, so region_var_of's fallback answers the default region for it. Sound, and it reclaims less for multi-argument functions than C does.

The closure adapter hands over the default region explicitly, because a closure value has nowhere to carry one — which is also what any call site reaching a function that way will have settled on.

The bug that made it look like the region was not reaching the callee

The first version emitted nothing at all, and the reason is worth keeping: every decl name in this backend carries a uniform `mu_` prefix, and the table that made the mangled part does not. So source_name_of_llvm missed every name, region_params_for answered the empty list, and the output was byte-identical to before — indistinguishable from the region genuinely not reaching the callee. A lookup that fails silently and a mechanism that does not apply produce the same emitted code.

parity 174 / 0. dune runtest 2717 / 0. escape 20 routes, 0 holes. 13 downstream repositories type-check. m3d: linalg, gltf, raster, shade, questions, northstar (50 images) and bench all pass — and its own 0.7 MB a frame is unchanged, for the reason v0.1.465 recorded: it has one region block and no call site inside one.

v0.1.465 — 2026-09-09

A correction to yesterday's own measurement: `__heap` is a `TyRef` and is not a block, and the report was counting it as one. v0.1.462 said m3d had eight call sites inside a region block. It has zero. So does the 286-program examples corpus.

The classifier's first arm matched any TyRef (_, r, TyUnit) and called it named, which __heap — the default region — satisfies. The emitted C is what disagreed: 116 region parameters declared and forwarded in m3d, and not one call site passing a real block.

m3d has one `region` block in the whole program (src/view.mere:197, in the window path), and the bench that measures its 0.7 MB a frame renders through --out, which does not go through it. So v0.1.464's closing note — "a precision gap to measure next" — was wrong about what the gap is: the region-passing machinery is not missing anything on m3d, m3d is not asking it for anything. The 0.7 MB a frame has been waiting on a region block that the measured path never opens.

That is a better problem to have, and it is m3d's to try: put the frame loop in a block and see whether the number moves. What this repository can say is that the mechanism works — test/regionparams/chain.mere carries a block's arena three frames down, and test/regionreclaim/percall.mere went from 80 MB to 4.3 MB on the strength of it.

A measurement that cannot tell "the default region" from "a region" answers the question it exists to ask with the wrong number, and it did so for three versions.

dune runtest 2717 / 0. The chain fixture's line is unchanged (1 named, 2 forwarded, 1 undecided), which is what says the correction did not move the case that matters.

v0.1.464 — 2026-09-09

Q-127's remaining half, closed on the C backend: a function allocates where its caller decided, because the caller hands it the region.

mu_deep__direct(__region_A, __da0)      the call written inside `region A { }`
mu_wrap__direct(__rp1352, __da0)        deep forwards its own parameter
mu_build__direct(__rp1350, __da0)       wrap forwards its own
  mere_vec_int_new(__rp1345)            and build allocates in what it was handed

Three frames down, and no rule for chains: wrap instantiates build at `wrap`'s own quantified variable, so reading the call site inside wrap gives wrap's parameter. Unification did the propagation; the backend only reads it.

This is the change that broke m3d for three versions, done the other way round. v0.1.453 let the callee's BODY reach for whatever region was current at run time, which in a chain is the block around the outermost call while every type said the default region. Here the CALL SITE reads what it bound and passes it, so the type and the value say the same thing — and where nothing bound it, what gets passed is the default region, explicitly.

Where it had to be keyed, which is the part that took two attempts

A first attempt read the region parameters out of the fn_decl's types and emitted nothing at all: `Monomorph.erase_container_regions` replaces every container's region with `__heap` before those types are stored, deliberately, so a region never splits an instance and Typer.unify at a monomorphisation site does not fail on two different region names. Preserving __rp there instead just moves the failure into unify.

So the region rides beside the type, keyed by the source name — which is what it is a property of anyway. A call site already has that name; Monomorph.instance_of is handed it before it mangles anything. A declaration only has the mangled name, so the map is rebuilt from the table that produced it, rather than by adding a field to fn_decl that a second place would have to keep agreeing with.

And the schemes are recorded at the inner `Let`, not at Pipeline's top-level one: the compiling path has no top-level let, because desugar_program turns every one into a nested Let. The first version recorded in the place that reads like the right place and recorded nothing.

What was checked, and what did not move

• m3d, the program that killed v0.1.453: linalg, gltf, raster, shade, questions,

render_props, northstar (50 images), bench, and reference_check (49 models against three.js) all pass.

• The escape check still refuses the dangerous shape, and nothing new was written for

it: test/escape/callee_built_into_vec.mere is GATED on all four backends and the interpreter, because the call site binds build's region to A and storing into something that outlives the block is a type error by name. That is the whole argument for passing the region rather than guessing it — the type follows the value.

• The self-tail-call loop is intact. Region parameters lead, so a goto that reassigns

only the tracked parameters leaves them alone; the call site declines the goto if a call would hand one back changed. 20M iterations at -O0 still run in constant stack.

• 13 downstream repositories still type-check. parity 174 / 0. dune runtest 2717 / 0.
• m3d's own 0.7 MB a frame is unchanged, and the emitted C says why: 116 __rp

occurrences, and not one call site passes a real block — all 57 pass the default region. The eight call sites its own --dump-region-params reports as inside a block do not reach the __direct path. That is a precision gap to measure next, not a correctness one, and it is stated here rather than left for someone to discover from the bench number not moving.

region_reclaim_check now asserts C reclaims and LLVM still does not, so the leg goes red when LLVM is taught too. region_params_check asserts the C output contains a region argument — "no __rp anywhere" was true when nothing passed one and would stay true if the region stopped reaching the callee.

v0.1.463 — 2026-09-09

The region parameters have names now, and nothing passes one — which is the whole point of shipping it separately. The change that closes Q-127's remaining half moves a function's allocations from the default region into whatever region its caller decided. That is the change that broke m3d for three versions. So the plumbing goes first, on its own, where "did anything move?" has the answer no and can be checked.

A quantified allocation region that appears in a scheme's type — one a call site could decide — is linked at emit time to __rpN, where N is the variable's own id. Everything still undecided after that becomes the default region, exactly as before. And __rpN also lowers to the default region, so the emitted code is unchanged.

Why the name comes at emit time and not when the variable is found: instantiate_with_map reads through Ast.walk, so a linked variable stops being copied per use, and every call site would end up sharing one region. It has to be after all inference is over.

Why the name is the variable's own id and not a per-function index: the declaration and the call site then do not have to agree on a numbering — they agree because it is the same variable. Order, where it will matter, comes from walking the type, which both ends already do.

What is checked, since nothing observable changed

• `#bound 3` on the chain fixture. "The pass ran" and "the pass did anything" are

different claims and only the second is worth a gate; poisoned by making the pass link nothing, and it says so.

• Zero occurrences of `__rp` in the emitted C, LLVM IR and WAT. A name in a type that

reaches the output as an identifier is a compile error, or an LLVM use of undefined value — which is precisely the bug v0.1.459 fixed, arrived at by assuming a name in a type is a name in scope. Three backends, asserted separately.

• The table is reset per program, beside reset_send_constraints, for the same

reason: the LSP re-checks the same process on every keystroke, and one emit would otherwise leave every later run's variables already linked and stop new ones being recorded.

dune runtest 2717 / 0. parity 174 / 0. region_reclaim 8 checks — still recording that a callee-built container is NOT reclaimed on C and LLVM, which is the thing the next slice is supposed to change.

v0.1.462 — 2026-09-09

The mechanism the rest of Q-127 turns on, validated before anything is built on it — and it needs no new machinery, because unification already did the hard part.

The remaining half of Q-127 is closed by passing a function's allocation region in as a hidden argument. The question that decides whether that is writable at all is: at a call site, what would you pass? mere --dump-region-params now answers it, per call:

@wrap -> build : ^param        forward the caller's own region parameter
@deep -> wrap  : ^param        again, one level out
@<top> -> deep : ?             no block here -- the default region, which is today
@<top> -> deep : A             inside `region A { }` -- pass __region_A

No side table, and no rule for chains. instantiate_with_map makes a fresh copy of each quantified variable per use and infer stores the instantiated type on the Var node, so the scheme's body and that node's type have the same shape: walking them in step reads off what each region variable became. And wrap instantiates build at `wrap`'s own quantified variable, so the call site inside wrap reads wrap's parameter. The chain propagates because unification propagated it.

That is the whole difference from v0.1.453, in one line: there the BODY guessed the runtime current region, which is wrong for a chain and cost three released versions and m3d's second frame. Here the CALL SITE reads what it bound and hands it down.

The numbers, on programs that exist

m3d is the program that killed v0.1.453, and Acc.floats — the function whose allocation did it — is in its list with one region parameter and status ok. Eight call sites would actually change behaviour; 142 exist to carry the answer to them. The examples corpus has no named sites at all, because almost none of it opens a region block: for most programs this change is inert, which the earlier "110 functions, all ok" number could not have told you on its own.

test/regionparams/chain.mere pins those four lines exactly, and the gate was poisoned by inlining one link — the two ^param lines vanish and it says so.

And a counting bug in the gate, found by its own new output

The corpus sweep read the first # line of the report to get its totals. The report now emits #sites ... before the summary, so the sweep started counting 289 call sites as 289 value-used functions and printed it without blinking. It reads ^# now. A summary line will state whatever it is handed.

dune runtest 2717 / 0. parity 174 / 0.

v0.1.461 — 2026-09-09

A correction to v0.1.460's gate, and the thing it got wrong is the oldest one in the book: its known-failure list was a photograph of this machine.

region_params_check sweeps examples/ and requires every program that does not type-check to be on a list, by name, so that a newly-broken example cannot quietly replace a previously-broken one. The list was written from what failed here. Three http_* examples import github.com/284km/mere-markdown/..., which resolves out of .mere_modules/ — git-ignored, populated by mere install, present on this machine and absent on the runner. Green here, red on CI, naming three files.

Failures are classified by REASON now. An unresolvable import is a fact about the checkout, so it is skipped and counted; anything else is a fact about the program and must be on the list, which now holds only the four deliberate ones (a type error, two lexer limits, a parse limit). stream_lines, which imports contrib/ relative to the repo root, stops needing a name — it is an import skip like the others.

Verified by reproducing the runner rather than by reasoning about it: with .mere_modules/ moved aside the gate still passes and reports 283 examples, 4 skipped, 102 functions, against 286, 1, 110 with it. Both are true; neither is a failure.

And an unexpected failure now prints the compiler's first line. "stopped type-checking" with no reason cost a thirty-three-minute CI round trip to ask what the reason was — a refusal has to name what it refused, and that applies to a gate's refusals too.

The measurement itself is unchanged: nothing is value-used or partial in either corpus.

v0.1.460 — 2026-09-09

Q-127 stage 1: the size of the change, measured instead of guessed. Nothing compiles differently. mere --dump-region-params lists, per function, how many hidden region arguments closing Q-127's remaining half would give it — and whether it can take one at all.

The remaining half is that a function's body allocates through the region variable in its own scheme while the call site binds a different copy: the type says the block, the value is in the default region. Passing the region IN is what makes those the same variable. v0.1.453 tried letting the body GUESS the runtime current region instead, and m3d's second frame is what said that is unsound for a chain, three released versions later. So the next attempt starts from a number, not an impression.

What it reports, and what it costs to be wrong about

Disqualified is not an error — those keep today's default region, which is over-strict and never unsound. So the ok fraction is the fraction of the problem the change would actually solve.

The numbers

Over 286 example programs: 110 functions would take a region parameter, all 110 `ok`. On m3d — the program that killed v0.1.453, and the only one here with a call chain deep enough to have done it — 40, all 40 `ok`. memo_fib reports zero, which is the other half of the answer: for most programs this change is inert.

That nothing is disqualified in either corpus is a result and not an absence of a detector: test/regionparams/valueused.mere and partial.mere exist so that both ways of saying no are seen to fire, and both were poisoned.

Also

--dump-region-params resolves imports relative to the FILE, the way running a program does rather than the way -t does. Two examples that -t cannot read type-check under it; one that imports contrib/ relative to the repo root cannot, and is on the gate's known list by name with the reason. A count would have let a newly-broken example replace a previously-broken one in silence.

scripts/region_params_check.sh is in CI. Three fixtures are the check; the corpus sweep is the measurement, with a floor on how many files it examined — a sweep that examined nothing agrees with every claim.

dune runtest 2717 / 0. parity 174 / 0.

v0.1.459 — 2026-09-09

A poison written to test a gate indicted the LLVM backend instead, and the gate it was testing is the one that pins the half of Q-127 that is still open.

The measurement first

region_reclaim_check asks whether a region block returns memory. It has always asked about a TREE built inside the block — a variant, which comes from the current region and is reclaimed. test/regionreclaim/percall.mere asks the other question, the one Q-127 is about: a container built by a function and returned, with only a scalar leaving the block, exactly as before.

C and LLVM hold every one of them: a container's region is in its TYPE, and a function's body allocates through the region variable in its own scheme, which the call site does not bind because the two hold different copies. The type says the block; the value is in the default region. Over-strict, never unsound — and it is the 0.7 MB a frame m3d pays. The leg asserts that this is STILL SO, so that whoever closes it finds out from a gate rather than from a paragraph. v0.1.443's LLVM leg is the precedent for writing it that way round.

Wasm reclaims it, and not by being cleverer: one bump for every region, nothing stores this vector into anything older than the block, so nothing raises the high-water mark (v0.1.458) and the rollback takes it. Right answer, unrelated reason — so the three legs assert three separate claims rather than that the backends agree.

What the poison found

Poisoning that leg means making the allocation lexical, which is what a fix would look like. The poisoned program did not build on LLVM:

use of undefined value '%__region_R'
  %t5 = call i64 @__lifted_f_0(ptr %__region_R, i64 %d, ptr %t4, i64 0)

v0.1.453 gave a lifted inner function its enclosing region as a leading parameter, so a body called from a nested block allocates where it was WRITTEN rather than wherever is current (Q-131). The parameter is named __region_R — and on the C backend the block's arena local is also called __region_R, so emitting the capture's own name as the argument happens to name the right thing. LLVM calls the arena %t4. Emitting %__region_R there is invalid IR.

`mere -ll` exited 0 the whole time. Only the assembler objected, and only if somebody ran it. The shape needs a let rec inside a region block inside a FUNCTION: every existing region/inner-fn parity case puts its block at the top level, where the two naming conventions coincide. Five versions.

Fixed by resolving a __region_* capture through current_regions — the same place region_ptr_for looks — at both sites that build capture arguments, the direct lifted call and the closure env. test/parity/region_inner_rec_in_fn.mere is the nine-line shape, confirmed to fail on a build of 2f1e180 with exactly that message.

And the gate's own bug, which the same poison showed

When the percall legs could not build, the section skipped and the PASS line then read its own unset variables: set -u killed the run with a shell error instead of a sentence. A leg that quietly does not run reports the question answered. Build failures are named failures now, the C and LLVM legs are separated so the message says which, and the run needs 7 checks rather than 4.

parity 174 passed / 0 failed. dune runtest 2717 / 0. region_reclaim 8 checks.

v0.1.458 — 2026-09-09

Q-132 closed, one day after the witness that found it — and it was twice as big as that witness showed. Every region in the Wasm backend shares ONE bump pointer, so an allocation made anywhere during a block is inside the block's range and the rollback takes it, whatever the value's type says about where it lives. Three shapes, all measured against v0.1.457:

The third is the one that matters for how this was missed. The backend did refuse escaping stores — but the refusal was syntactic, so it never saw the first two (the store is three frames down, not in the block), and it exempted unboxed elements on the ground that an int cannot dangle. The int cannot. The buffer can: vec_push grows a full container by allocating, that allocation comes off the same bump, and the rollback took it. The exemption was true about the value and false about the container.

The fix is to stop reclaiming, not to keep refusing

A store into a container that predates the innermost open block raises a high-water mark to the current bump; the block's exit restores max(its mark, hwm). Sound because the value stored, and any buffer the store reallocated, were allocated before that point and lie below the bump. Conservative because the block keeps its other garbage too — which is exactly what the C backend does with a __heap value: never frees it. So this makes Wasm agree with the semantics the types already claimed, rather than inventing new ones. One global compare when no block is open; nothing for a block that touches only its own containers. region_reclaim is unchanged: C flat at 2 MB, LLVM flat at 5 MB, Wasm inside 64 MiB.

And the refusal is gone, because its stated reason — "the backend reclaims the whole block on exit and has no per-container storage to copy into" — is no longer true, and because a guard that has to be right about every store in the program cannot be syntactic. What is still refused is what a mark cannot help with: channel_send, spawn, and closure-registering externs hand the value to another thread or to the host, on no schedule ordered with the block's exit.

Five things the gates said, in the order they said them

1. `test/parity/region_chain_callee_alloc.wasm.expected` went stale within the day.

It was installed the previous version to pin the wrong answer; parity's reply to the fix was wasm matches now — delete the stale pin. Deleted.

1. `test/escape/ROUTES` has no open holes again — callee_alloc_chain is promoted

from HOLE to SAFE. Its row read ACCEPT everywhere the whole time, which is the lesson kept in the header: when four backends agree on a verdict, that is not four backends agreeing.

1. Three routes stopped being unreadable on Wasm. str_out, variant_of_str and

closure_out had all been refused by the store guard too, so their -w column was recording a subset limit rather than a verdict. The gate caught the stale listings.

1. Two parity programs gained a fourth backend: region_closure_value_nested and

region_inner_fn_nested — the Q-131 witnesses — were Wasm-UNSUP only because of the guard. Wasm's blind spot is 12 of 173, down from 14 of 172.

1. A unit test asserted the opposite and now asserts the store compiles, with the

refusal it used to pin re-pointed at channel_send, which still needs it.

test/parity/region_outer_push_realloc.mere is new and is the third row of that table: a separate program from the chain witness because it is a separate mechanism — that one is about the value stored, this one about the buffer the store moves. Both were run against a build of 5fca98b to confirm they fail there (-424242, -7) and pass here.

parity 173 passed / 0 failed, no declared divergences. dune runtest 2717 / 0. escape_check 19 routes, 0 open holes.

v0.1.457 — 2026-09-09

The witness this repository did not have — and it found a live bug on its first run. v0.1.456's lesson was that three released versions shipped a memory-safety change whose only witness lived in another repository. dune runtest, parity, every gate and all 29 dogfood type-checks were green while m3d could not render a second frame. The obvious follow-up is not a note; it is the program.

test/parity/region_chain_callee_alloc.mere is that program, and it is small:

let cache = vec_new ();                                 -- top-level, so its region
let leaf = fn (n: int) -> .. vec_new () ..;             --   variable is not quantified
let fill_cache = fn (n: int) -> vec_push cache (leaf n);
let mid = fn (n: int) -> fill_cache n;
let top = fn (n: int) -> mid n;
let _ = region A { top 700 };                           -- the block holds ONE call
let _ = region B { .. 4096 pushes of -424242 .. };      -- reuse A's arena
print_int (vec_get (vec_get cache 0) 0)

The allocation happens three frames below the block, where no region is lexically active, and it reaches a container that outlives the block. Built at 62e1858 (v0.1.455) this prints 700 on the interpreter and -424242 on C — the value the second block scribbled, read through a pointer into the first block's reclaimed arena. At HEAD both print 700. The type says __heap either way, so no escape check can fire on it; only running it separates the two answers, which is exactly why nothing here separated them for three versions.

region B is not decoration. An arena is REUSED rather than freed, so with only one block the stale pointer still reads 700 and the bug looks absent — and ASan is blind to it, because the arena is one live allocation.

And Wasm answers -424242 today. That is Q-132.

The Wasm backend has one bump pointer for every region, so an allocation made anywhere during a block — by a callee, three frames down, with a type that says the default region — sits inside the block's range and is rolled back with it. The backend does reject escaping stores, loudly and by name, but its guard reads the block's own body: it cannot see an escape a callee performs.

Not fixed here, because a fix is either per-region storage in Wasm or a call-graph-aware guard, and both are a slice of their own. It is PINNED twice instead, in the two places that can each detect it being fixed:

• test/parity/region_chain_callee_alloc.wasm.expected holds -424242 exactly. Any

other output is a DIFF, and the right output makes the pin stale, which parity reports as a failure telling you to delete it.

• test/escape/ROUTES gains callee_alloc_chain HOLE ACCEPT ACCEPT - Q-132 — the

first open hole that table has held. It is unlike the others: the row reads ACCEPT everywhere because the TYPE rule is right (nothing escapes, on the reading the types have) and three of four backends implement that reading. The hole is in one backend's storage model, which a verdict column cannot show. The header now says so.

Five comments that claimed the withdrawn behaviour

emit_program in all four compiled backends said an undecided allocation region "becomes __caller (the runtime current region ...)". It does not, since v0.1.456. So did the shared-pass note in codegen_llvm and the Q-127 note in test_basic. All five now state what the code does and, briefly, what it did and why that was withdrawn — a comment describing behaviour the code no longer has is the failure mode m3d's own "this would stop compiling" note had just been caught in.

parity 172 passed / 0 failed (one declared divergence: wasm/region_chain_callee_alloc). dune runtest 2715 / 0. escape_check 19 routes, 1 open hole.

v0.1.456 — 2026-09-09

A CORRECTION to v0.1.453, and the claim it withdraws is the headline one. Q-127 said a container a function builds should live in the region the CALLER is standing in, and settled an undecided allocation region on __caller, which the backends lowered to the runtime current region. The argument was that a call does not change the current region, so inside the callee it must be the region open around the call. That is false for a chain of calls, and m3d is the witness:

region FR { render_at o }      -- render_at -> one_frame_into -> attr
                               --   -> Acache.floats -> Acc.floats

Only the outermost of those is written inside a block, so only its copy of the region variable is bound. Acc.floats's BODY allocates through the scheme's own variable, which nothing bound — and lowering that to the current region put the value in the frame's arena while every type involved said the default one. m3d stored it in a cache that outlives the frame and read it back after the arena was reused: a segfault from the second frame on, in v0.1.453, 454 and 455.

The body and the call site hold DIFFERENT COPIES of the variable. The only ways to make a body allocate where its caller decided are to pass the region in or to specialise per region, and neither exists yet. So an undecided region is the default region again — what it has always meant, and safe. `region R { let v = build .. }` reclaims nothing again: the 822 MB → 10 MB measurement is withdrawn.

What survives, and it is not nothing

The types still name the block, so the escape check still fires. Binding at the call site was doing two jobs and only one of them was unsound. Carrying a callee-built container out of a region block is a type error, reported by the check that was already there — being typed to a region the value does not actually live in is over-strict and never unsound, which is the direction this now errs in.

Every GATED route in `test/escape/ROUTES` is REJECT on the interpreter too. Ten of them read ACCEPT before, with the honest explanation that the interpreter has no arenas so nothing dangles there — but the escape rule is a TYPE rule, and one the toolchain only half applies is a rule with a hole. The hole was at the top level: let o = vec_new () was generalised over its region, so a store inside a block bound a COPY and o's own type never mentioned the block. Giving the top-level let the value restriction the inner one has had since Phase 36 makes it one variable and the check fires. One program, one answer.

And that restriction now exists in one place. Pipeline had the top-level let written out THREE times — process_decls, infer_program_inner, type_of — and they had drifted; the interpreter and -t disagreed about the same program for a while today because two of them had it and one did not.

The lesson, since it cost three versions

The premise was checked against a witness that did not distinguish it: a call made directly inside a block, where the runtime current region and the caller's binding coincide. The case that separates them needs a CHAIN, and the corpus had one — m3d — that nothing in this repository runs. dune runtest, parity, every gate and all 29 dogfood programs' type-checks were green while three released versions could not render a second frame. The bench that would have caught it is in m3d's repository, not this one.

One cell in the host matrix stopped being about something else

bytebuf_new's LLVM cell has read unattributed since 2026-08-30, when that value was invented for a probe that cannot reach its subject. It was one: let _ = bytebuf_new 1; 0 never got as far as the backend's host-builtin check, because the ByteBuf's region slot was still a type variable and ty_tag refused THAT first — unsupported LLVM codegen type element: 'a. The message matched unsupported and named no builtin, so the harness correctly said the cell was about something else.

Defaulting an undecided region settles the slot, the probe reaches its subject, and LLVM refuses in its own name: bytebuf_new has no LLVM lowering yet (host builtin). refused. Fourteen rows still have such a cell; this one was hiding behind a type the backend could not spell.

parity 171 passed / 0 failed. dune runtest 2715 / 0. m3d's four bench models run.

v0.1.455 — 2026-09-09

An exported call *is* a region, and the typer knows it now. mere -c --lib compiles a shared library whose boundary opens a region per call and releases it at return — that is what makes a call a transaction, and it is why v0.1.311 stopped pinning containers to the default region there. Nothing enforced the other half of that bargain: a host that stored a callee-built container into module state and then made one more call read back garbage, because the arena had been reused. Pinned as a known gap in v0.1.452, with the instruction that whoever closed it should delete the pin and say so.

It is closed, and not by choosing a region. A top-level function's body is now typed inside the call's region, so the store is the same mistake as carrying a value out of a region block and gets the same treatment:

region escape across the library boundary: `store` now holds a value built during a
call, which is freed when that call returns (its type became `Vec['a, Vec[__call, int]]`).
Each exported call runs in its own region -- build it at module init, or copy its
contents out

lib_check keeps its section and checks the new claim in both directions: the store is refused and names the binding, while a call that builds containers and keeps none is still accepted with them in the call's own arena. A gate that refused everything would pass the first half and be useless.

And the mode-dependent answer is gone. heap_container_region said "the current region" in --lib mode and "the default region" otherwise; Q-127 makes that unnecessary and, with it, wrong. A container a CALL builds now carries __caller, which is the current region already, so the leak that special case existed for stays fixed by the general rule. What is left as __heap belongs to something outliving the call — module state, or a pass-through — and sending those to the per-call arena was the defect itself.

Two things fell out that were on m3d's list, not on this one

`bytebuf_new` never bound its region to the block it was written in. Unlike vec_new, map_new and strbuf_new it was a plain polymorphic scheme, so the marker stayed open and settled on the default region — which is never freed. m3d measured that as row 1 of its Q-10 table and paid for it twice, allocating its render target once and clearing it per frame because a region around a frame reclaimed none of it. It binds like every other container constructor now: 676 MB → 268 MB on Q-10's own measurement (200 iterations of a 4 MB buffer inside a block). test/parity/region_bytebuf_reclaimed.mere.

A record field can hold a `Vec` now (m3d's Q-8). type box = { v: Vec[R, float] } answered expected &R unit, got &__heap unit: the field's declared region was the rigid name R and vec_new () produced the rigid name __heap, and two rigid names do not unify. A function taking or returning one worked, because a signature can be generalised over the region and a field cannot — so the shape a record wanted was the one shape that could not be written. With the marker a variable until something decides it, the field's declaration is what decides it. ByteBuf always worked and was the exception that gave it away: its region is erased from the tag, so the mismatch never arose. test/parity/record_holds_containers.mere.

The top-level let, typed once

Pipeline had the same eight lines twice — process_decls, which the interpreter walks, and infer_program_inner, which every backend starts from — and they had drifted: neither applied the value restriction Typer's inner let has had since Phase 36. While every region settled on __heap that did not show. Q-127 made it show: let store = vec_new () was generalised over its REGION, so each use instantiated a different one for a container there is only one of. One function now, called from both.

parity 171 passed / 0 failed. dune runtest 2715 / 0. All 29 Mere programs in the dogfood corpus type-check unchanged.

v0.1.454 — 2026-09-09

A function written inside one region and called from a region nested inside it allocated in the wrong arena, and the value died with the inner block. Q-131, found while designing Q-127's fix and confirmed with a witness:

region R {
  let mk = fn (n) -> let v = vec_new () in .. v in   // typed Vec[R, int]
  let cache = vec_new () in                          // Vec[R, Vec[R, int]]
  let _ = region S { vec_push cache (mk 700) } in    // mk's body ran with S current
  ..                                                 // interp 1 / 700, C 4096 / -1
}

Every type here is consistent and the escape check is right to say nothing: the value is typed R and stored in R. What was wrong was the ARENA. mk is lifted out of the block into its own function, so the block's __region_R local does not reach it, and v0.1.433 made it fall back on the RUNTIME CURRENT REGION — "the answer a lexical name cannot give". At the call the current region is S, not R.

The region travels with the function now. A lifted body takes each region block it was written inside as an ordinary capture, named __region_R — which is already the C local the block binds, so the parameter, the argument the call site passes and what region_var_of answers are one string. Typed as the region marker, which c_type_of lowers to __lang_region*; the env struct, the closure adapter, the __direct twin and the transitive capture fixpoint all treat it as a capture and need to know nothing about regions. A lexical name CAN give the answer, provided it is carried rather than looked up.

Two paths, two witnesses, because fixing either leaves the other. The C backend lifts let mk = fn .. inside a block to a function with a leading region parameter; the LLVM backend makes it an anonymous closure and carries the region in its environment. test/parity/region_inner_fn_nested.mere is the first, region_closure_value_nested.mere — the same function passed as a VALUE — is the second. Poisoned separately: removing the C capture makes the first read 4096, removing the LLVM one makes the second read 4294967295.

Both witnesses end with a third block that writes 4096 words over the arena. Without it the stale bytes read back correctly and the bug looks absent — the arena is REUSED, not freed, which is also why a sanitiser cannot see it: it is one live allocation.

Also

• The Wasm backend's refusal for a store into an outer container from inside a block now

says "unsupported in Wasm codegen subset". The phrase is not decoration: parity.sh reads it to tell a documented limit from a backend that fell over, and worded as "not supported yet" this deliberate refusal was tallied as an EMITFAIL — the first parity case to exercise it made the harness red for a program it had correctly refused.

parity 169 passed / 0 failed. dune runtest 2715 / 0.

v0.1.453 — 2026-09-09

A container a function built landed in a region nothing frees, and a `region` block around the call reclaimed none of it. let build = fn n -> let v = vec_new () in .. v came out as int -> Vec[__heap, int]: the container's region was decided when the FUNCTION BODY was checked, where no region is open, so every call site got the same answer — the default region, which is never freed. Two hundred iterations of a half-million-element Vec built through a call inside region R { } reached 822 MB; m3d measured the same thing as 0.7 MB a frame and had to work around it twice. Recorded as Q-127.

The region is now decided by the CALL SITE. Outside a region block the marker starts as a variable rather than the name __heap, the binding generalises over it, and each call binds its own copy to whichever region is open around that call. The same program is 10 MB, and the other half arrives with it: carrying such a container out of the block is a type error, reported by the escape check that was already there —

region escape: `cache` now holds a value from region `A`, which is freed at the end
of this block (its type became `Vec['a, Vec[A, int]]`)

Nothing new checks anything. The type stopped lying, and a check written for region R { let v = vec_new () in .. } in v0.1.291 started seeing the case it was always about.

Quantified AND allocation, which the first attempt got wrong

Only a region a call ALLOCATES INTO is the call site's to decide. let id = fn (v) -> v passes its argument's region through and touching it would be wrong, and the difference is not always visible in the type: mere-ruby's frame pool returns either a pooled map or a fresh one, so the fresh map_new's variable is UNIFIED with the global pool's, and which of the two survives is unification's business. Binding it retyped the global as living in the block, and the escape check reported it — correctly by its own lights.

Level discipline already separates them: a variable shared with the environment is not local to the binding, so generalize declines to quantify it. Every marked variable generalisation declines is unmarked there, once, and non-local never goes back. With that, all 29 Mere programs in the dogfood corpus type-check unchanged — including m3d, whose frame loop had already been written to this discipline ("a value created in this region could not be stored in a cache that outlives it. Hence the warm pass above, out here, and a lookup inside that never writes").

No hidden argument, because a call does not change the current region

A region left undecided settles on __caller, which the backends lower to the RUNTIME CURRENT REGION. That is not an approximation: the current region changes at a region block and nowhere else, so inside the callee it is exactly the region that was open around the call — the same one the typer bound the caller's copy to. The two agree by construction rather than by a rule written twice, and a function called from three regions needs one body, not three.

The alternative was measured and rejected. Specialising per region needs the region to distinguish instances, and the region is deliberately not part of the C type (Vec[R, T] and Vec[__heap, T] are both mere_vec_<T>*, the region a pointer inside the struct). Those two requirements are not compatible: every attempt fixed one and broke the other.

The tag stopped naming the region, in all four backends

ty_tag kept the region for Vec and Map while already dropping it for StrBuf and ByteBuf — and the note on that exclusion said why: it "removes the whole class of mismatch where one spelling resolved the marker and the other did not". With three spellings in play the class came back immediately, as %tuple_Vec___caller_str.. against %tuple_Vec___heap_str.. in the same LLVM function. The region is out of the tag everywhere now, and arrows are compared and unified modulo container regions for the same reason.

That cuts both ways on size, and both directions are the same cause. mere-ruby's emitted C is 2.8% smaller (633 KB) because instances differing only by a region collapse into one; examples/live is 3.9% larger and m3d 1.5%, because a generic helper whose only unresolved variable was a region used to be unnameable and therefore silently dropped — an accidental dead-code pass that this removes. The wasm_live band moved for that reason; there is no reachability pruning for top-level functions, and until now an accident was standing in for one.