Changelog (mere)

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

v0.1.294 — 2026-08-22

_Every formatted value leaked its scaffolding._

Both native backends build a formatted string in an asprintf buffer, copy it into the current region at the __lang_str_of_cstr boundary -- and never free the buffer. One vasprintf buffer is 160 bytes on macOS, so a million str_of_int calls leaked 48 MB. The list formatter was worse: it rolled its accumulator through asprintf on every element (__acc = __buf), leaking the whole previous prefix each step -- quadratic bytes in the list length.

Found from the outside: mere-ruby's new bench/region_reuse.sh asked whether a region whose block chain GREW past one block hands its memory back in a reusable form (the property a compaction loop stands on), and the answer looked like no -- peak footprint grew linearly, ~38 MiB per iteration, while the runtime's own block counters insisted everything was returned. A minimal C probe cleared libc (the same malloc/free pattern is flat at any iteration count), and leaks named the 300,000 vasprintf buffers.

The boundary now has an owning twin: __lang_str_take_cstr copies into the region and frees its argument. All 13 asprintf sites in the C backend and all 6 in the LLVM backend go through it; getenv/argv/literal sites stay on the borrowing one. The C list/json formatters free their rolling accumulator.

After the fix the original question answers itself: released grown chains are fully reusable through plain libc -- 1, 8, and 32 sibling ~64 MB regions all peak at 36-39 MiB. No runtime block pool is needed.

parity 119/0, dune test 2536/0, ctest, stack_overflow, selfhost_check, url/encoding parity, debug_info, wasm_sourcemap, lsp_smoke -- all run locally before push, plus leaks --atExit reporting zero on the probe and on a list-show program.

v0.1.293 — 2026-08-21

_Whoever names a copier decides that it exists._

v0.1.290 taught __mcopy for an arrow type to deep-copy a closure's env, which put copier CALLS in two places that had never emitted one before: a record's copier, for a field holding a closure, and an env copier, for a captured value. CI went red for four releases -- 16 of 119 parity programs, every trait_* one among them -- with the emitted C naming a function that was never defined:

v.mu_add = __mcopy_closure_int_closure_int_int(r, v.mu_add); / undeclared /

Two independent faults, each hiding behind the other's failure.

The first: `ty_tag` names types that `ty_is_concrete` rejects. ty_tag erases an unresolved type variable to int, so a capture of list (str, 'a) is named __mcopy_list_tuple_str_int -- while the collector that decides which copiers to emit walks the same type, finds it not concrete, and drops it. A name with no definition. Registration now goes through ty_as_tagged, which returns the type ty_tag actually names, including the region slot that ty_tag renders as __heap (erasing that to int would reintroduce the mpng P5 shape: one type under two names).

The second: a polymorphic record's fields were read three times, and two of the readers had a different answer. A trait dictionary Num__dict 'a is monomorphized at its instance -- for Num__dict m7 the struct field is closure_m7_closure_m7_m7 -- but the copier emitter read r_fields directly and named __mcopy_closure_int_closure_int_int, the wrong type under the wrong name, while the collector dropped the field entirely for holding a TyParam. Only the closure-typedef collector, which had hit this before, substituted the arguments. The rule now lives in one place, record_field_types_at, and all three read it.

Also: the inner-lifted half of the env-copier list is no longer filtered on captures = []. A closure with no captures has no env at all and needs no copier; an inner-lifted fn always gets an env struct and its use site assigns __copy unconditionally. Measured, not reasoned -- restoring the filter fails exactly one parity program (prop_list).

Gates: parity 119/0 (was 103/16), dune test 2536/0, plus ctest, stack_overflow, host_matrix, selfhost_check, url/encoding parity, infer_scaling, debug_info, wasm_sourcemap, lsp_smoke, window_check -- none of which CI had reached since v0.1.290, because it stops at the first failing gate.

v0.1.292 — 2026-08-21

_The copier moves into the env, and a closure is two pointers again._

v0.1.290 put the env copier in the closure struct, which made a closure three pointers. v0.1.291 answered the cost by emitting two different closure shapes -- three pointers for programs that use a region, two for those that do not. That is two rules where there should be one, and it left the memory win unavailable to exactly the programs that wanted it: an interpreter that adds a region block to reclaim its temporaries pays the pointer on every frame of its dispatch, and one of CRuby's bootstraptest pairs loses its stack (ld caps -stack_size at 512 MB on arm64, so there is no room to buy back).

The copier now lives in a header on the ENV: {__lang_region* __r; void* (*__copy)(__lang_region*, void*);} at the front of every env struct. __mcopy for an arrow reads it through the void* it already has. The closure struct is {env, fn} again, for every program, and the region-conditional emission and the typer flag it needed are gone.

An FFI adapter used to hold a borrowed pointer directly as its env, which a header cannot be read from. Those envs are now real structs -- a header plus the borrowed pointer -- allocated in the default region with __copy = NULL, which says "do not copy me, I am permanent" in the same field that says "copy me like this" for a generated env. One rule, read the same way everywhere.

Measured on an interpreter written in Mere: with a region block per statement, 200k plain method calls hold 1181 MiB against 1358-1996 before, the same number three runs out of three, and run in 1.16-1.20s against 1.43-1.58s. Its corpus is 157/157 either way.

Two sentences in the first version of this entry were wrong, and the correction is worth more than they were. They said the memory win now costs nothing and that CRuby's bootstraptest was back to its baseline. Neither holds: the pair v0.1.291 was written around still fails with the closure at two pointers, so the third pointer was not its cause -- or not its only one. That pair runs a thread with while true; // =~ "" end beside a regex loop, and whether it finishes depends on which limit trips first, the interpreter's step budget or the native stack. The same source overflows at -O1 and does not at -Os: a canary on the line, not a measurement of a change. The interpreter's own record now says so, so that its err=59 is not read as a fresh regression.

The reasons to prefer this shape stand without those sentences: one closure layout instead of two, no per-frame pointer, and an FFI env that answers the same question the same way a generated one does.

2536 tests pass across four backends.

v0.1.291 — 2026-08-21

_An env records its region, and a program that uses no region pays nothing._

v0.1.290 gave a closure a copier for its env and then copied unconditionally. That is neither idempotent nor bounded. An env that captures a closure copies that closure's env in turn, so a chain of them is a chain of copies, and a threaded test in an interpreter written in Mere overflowed the native stack: stack overflow (recursion too deep), where the same program passed before. Copying also duplicated identity — two copies of one env are two mutable states, and a closure that writes through what it captured would write to the wrong one.

Each env now carries the region it was allocated in, and the copier returns its argument unchanged when that region is the destination. Copies inside one region — the common case, and every copy in a program with no region blocks — become no-ops, and a cross-region copy still walks only as deep as the chain that actually crosses. This is the elision the memory model deferred as needing type-level region tracking on values; one pointer per env does it at runtime.

Found by CRuby's bootstraptest, run against an interpreter written in Mere: 1697 pairs, of which exactly one moved from pass to error. Neither that interpreter's own 157-program corpus nor this repo's 2533 tests noticed, because the shape needs a closure captured inside a closure inside a thread. A wider gate is worth having even when it is somebody else's.

The idempotence fixed the copying, and did NOT fix what the bootstraptest pair was actually measuring: v0.1.290 made the closure struct three pointers instead of two, and a closure is passed BY VALUE through every frame of an interpreter's dispatch. One pointer per frame took that program over its stack limit -- and there is no room to raise it, because ld refuses -stack_size above 512 MB on arm64, which is exactly where the interpreter already was.

So the copier is now emitted only for programs that USE a region block. With no region block __lang_current_region IS the default region, an env cannot outlive its region, and the closure keeps its pre-v0.1.290 shape: two pointers, an env in the default region, a shallow copy. Charging a cost to programs that cannot benefit is the wrong trade, and the measurement said which programs those are. Verified end to end: the interpreter rebuilt without a region block is back to pass=1569 err=58, its baseline, and its generated C carries no copier field at all.

The flag that answers "does this program use a region" is set by the typer, not during emission -- the typer walks the whole program first, and a closure may be emitted before the region block that appears later in the file. It is reset per compilation, because the language server and the test harness both compile many programs in one process, and a leftover true would give a region-less program the shape of whatever was compiled before it.

v0.1.290 also shipped with version.ml left at 0.1.289: its changelog entry was written after the suite ran, so the version test's failure was not seen before the commit. Both are corrected here.

v0.1.290 — 2026-08-21

_A closure carries the copier that lets it leave a region._

Closure environments were allocated in the default (program-lifetime) region, and the reason was written where the deep-copy family is defined: "closures copy shallowly: their envs live in the default region". A closure's env is a type-erased void*, so nothing could copy it into another region — and a permanent allocation was the only answer that could not dangle. The cost is invisible in a small program and decisive in a large one: an interpreter written in Mere allocated 2548 closure envs' worth of default-region references against 1346 current-region ones, so every call leaked whatever it closed over.

A closure now has a third member beside env and fn: void* (*copy)(region*, void*), generated per env type next to the env's own typedef, where the field types are known. It region-allocates a fresh env, copies the struct across, then re-copies each captured field through that field's own __mcopy_ — so a captured string is deep-copied rather than left pointing into the region that is about to be released. __mcopy for an arrow calls it when it is set, and a closure leaves a region block the way every other value does.

Two shapes deliberately keep the old behaviour, and get it for free from C's zero-initialization of omitted designated initializers: a closure with no captures passes env == NULL, and an FFI adapter holds a borrowed pointer it does not own. Both leave copy zero and are copied shallowly.

The test that asserted the old rule now asserts the new one, in the same three places it was checked: the allocation follows __lang_current_region, the closure literal carries .copy = __mcopy_env_..., and a captured str reaches the copier. 2533 tests pass across four backends; the change is C-only, since the other backends do not share this representation.

What this does NOT do on its own: an interpreter with no region blocks has __lang_current_region == &__lang_default_region, so nothing moves until the blocks exist. It removes the reason they could not pay off.

v0.1.289 — 2026-08-20

_A record field is a C struct member, and one name answered two questions._

The other half of the keyword surface. v0.1.286 routed a closure CAPTURE's name through c_safe_name; a user record's fields never went through anything, so type t = { short: str } emitted const char* short; — a keyword where a declarator belongs. Same argument as v0.1.56's, which chose a uniform mu_ prefix over a reserved-word list because the list "was inherently incomplete and recurred six times", so the same prefix is used and there is one rule to know rather than two. Fields live in a per-struct namespace, so a prefix collides with nothing; what it buys is that no C keyword reaches a declarator.

Fourteen sites: two definitions (the struct body and the monomorphised one) and twelve uses — literal, update, field access, pattern binding, show_, to_json, from_json, eq, cmp, __mcopy, and a map key's equality and hash. Plus two hand-written runtime literals, for mk_logger and mk_metrics, which spell the field names out and had to spell them the same way.

One real bug came out of doing it, and it is the interesting one. from_json used the same fname twice in one format string — once as the C designator and once as the JSON KEY. Prefixing both renamed every key in every serialised record, which four parity programs said immediately. The designator is an identifier and the key is what the document says; one name, two questions, and only one of them wanted namespacing.

And the loud-failure property earned its keep. Eleven assertions in the suite pin this struct's spelling from various sides and all eleven went red at once, which is exactly what v0.1.56 argued a uniform prefix would buy: a path that forgets it breaks every record rather than only the unluckily-named ones. Separating "the assertion is stale" from "the codegen is broken" was one measurement — the four JSON parity programs compile and run — and after that the assertions were bookkeeping.

Two sites were missed on the first pass and both were found by gates rather than by reading: the cmp line, because the replacement written for it was character-identical to the original and the patch skipped it, and mk_logger's runtime literal. host_matrix named the second in one line. mk_metrics is still nocompile on the C backend and was before this — a function pointer type mismatch, unrelated.

Verified on Darwin: dune runtest 2531/0, parity 119/0, ctest 14/0, host_matrix with no change, selfhost ok, stack_overflow ok. Verified on Linux in a container: fifteen programs through the C backend and eleven through LLVM, including a record with short, long and inline as field names, all matching the interpreter.

v0.1.288 — 2026-08-20

_The LLVM backend names a stack overflow on Linux, which took dlsym and a computed array length._

Three releases and two wrong shapes to get here, all of them the same underlying fact: LLVM IR has no preprocessor, so a runtime detail that differs by platform has to be selected at run time or not at all.

v0.1.285 made the Darwin-only pthread pair extern_weak and guarded the call, which stopped the link failure and left the bounds unknown off Darwin. v0.1.287 found that the handler was not even being installed there — stack_t, struct sigaction, the SA_* values and SIGBUS all differ — and selected seven measured constants off one icmp. What was left was the bounds, and the obvious move does not work: declaring pthread_getattr_np extern_weak breaks the DARWIN build, because Mach-O's linker refuses an undefined weak reference where ELF resolves it to zero. Measured, not assumed — it was tried and reverted.

dlsym(RTLD_DEFAULT, …) asks at run time and needs no reference at link time, which is what wanting an optional symbol actually calls for. Measured: it is in libc on both platforms, so no extra link flag, and RTLD_DEFAULT is itself platform-dependent — 0 against -2 — which the same icmp selects. glibc reports the LOW address and the size, the other way round from the Darwin pair.

platform C backend LLVM backend macOS/arm64 names it names it Linux/x86_64 names it names it Linux/aarch64 names it names it

So the divergence is gone and both the things that recorded it are gone with it. The parity pin for uncaught_stack_overflow is deleted, and scripts/stack_overflow.sh expects one answer everywhere instead of a per-platform one — if a platform stops naming the fault that is now a regression rather than a fact about the platform. The gate's second mode, for a backend expected not to name it, is removed rather than left: nothing reached it, and a branch nothing reaches cannot be told from a branch that is wrong.

One thing worth the line because it was caught late and cheaply: the three symbol-name constants had their array lengths written out by hand and two of the three were off by one. They are computed from String.length now. LLVM catches that, but only after the file is emitted, and nothing about the source made it visible.

v0.1.287 — 2026-08-20

_The LLVM handler installs itself on Linux, which needed seven measured constants._

v0.1.285 stopped the LLVM backend failing to link off Darwin by making the two Darwin-only pthread calls extern_weak and guarding them, and left the fault unnamed there. What it did not do was notice that the handler was not being installed at all: stack_t, struct sigaction, the SA_* flag values and SIGBUS are all different on glibc, so sigaltstack was handed a size where it expected flags, refused, and the early return meant no handler ever arrived. The process died with the shell reporting the signal.

The platform is a runtime fact here, not an emit-time one. IR has no preprocessor, and choosing when the IR is written would make -ll output specific to the machine that produced it -- which it has never been. pthread_get_stackaddr_np is already declared weak, so its address is non-null on Darwin and null everywhere else: one icmp and every constant below is a select.

Measured on macOS/arm64, Linux/x86_64 and Linux/aarch64 rather than recalled, because a wrong offset here writes a flag word into a signal mask and the handler simply never comes:

si_addr in siginfo_t 24 / 16 stack_t ss_size, ss_flags 8, 16 / 16, 8 struct sigaction sa_flags 12 (of 16 bytes) / 136 (of 152) SA_SIGINFO | SA_ONSTACK 65 / 134217732 SIGBUS 10 / 7

The observable difference on Linux is small and exact: Segmentation fault from the shell becomes segmentation fault from our own handler, and the exit status becomes 1 -- what the interpreter exits with -- instead of 139. So parity's pinned divergence for uncaught_stack_overflow moves from EXIT(139) to MSG: the process now fails the way the interpreter fails and only the message differs. The pin catching that is what it is for.

The name still needs the bounds, and that is one measured step away. The glibc pair is pthread_getattr_np + pthread_attr_getstack, and declaring them extern_weak does not work: ELF resolves an undefined weak reference to zero and Mach-O's linker refuses it outright, so adding them broke the Darwin build. dlsym with RTLD_DEFAULT is the portable way to ask for an optional symbol, and RTLD_DEFAULT is itself platform-dependent (0 against -2), which the same icmp can select. Not done here: it is a separate change with its own verification, and shipping it half-measured is how this release's predecessor got the layout wrong.

v0.1.286 — 2026-08-20

_A capture the walker forgot, twice, and the shape that needs three things at once._

The browser dogfood is the first program here to ask the C backend to compile something large, and it did not compile at all: 29 errors, in two families. The first was field names not going through c_safe_name and is fixed above. This is the second, and it is the one that had been invisible for a reason worth writing down.

`known` decides what is NOT captured, and `host_locals` is what rescues a name from it. known is builtins plus top-level names plus externs — things referenced directly in the generated C rather than through an env. host_locals is subtracted from it, which is how a frame-local that happens to share a builtin's name gets captured anyway. The top-level driver has always passed [f.param] for exactly this. Two places lost it.

A curried parameter's name was discarded. The walker's own Fun case read Ast.Fun (_, _, body), so descending through fn (cs) -> fn (id) -> ... recorded cs and forgot id — and id is the identity builtin, so it sat in known, and an inner let rec reading the parameter captured nothing. The lifted function then named an identifier that was never declared, reported by the C compiler thousands of lines from the decision.

And descending into a lifted body reset the list. walk_in_fn p [] fn_body threw away the enclosing frame's names, so one lift further in the outermost parameter looked like something already in scope. One level worked because the enclosing frame was the top-level one, whose parameter the driver had recorded.

Three things have to line up, which is why neither showed up before. The name shadows a builtin; it is a curried parameter rather than the first one, or read from a nested lift; and it is read from a lifted function. Any two of the three and the program compiles.

Two parity programs, one per defect, each verified to catch its own by reverting the fix. The second was written with an ordinary name first and passed with the fix reverted — it never reached the code it was for, and only poisoning said so. It names its parameter after a builtin now, and the comment says why.

MERE_LIFT_DEBUG=1 prints what this pass decided: per lifted function its host, parameter and captures, and per lift the body's free variables alongside the names known blocked. Kept rather than deleted after use — a missing capture surfaces as use of undeclared identifier in generated C, and the alternative to reading this is guessing which of the four skip conditions in the fixpoint fired.

The browser dogfood compiles now, and the measurement its north-star gate owed can be taken: a 559-byte page in 45 ms, of which 19 is loading the font and 18 is style and layout, at a 39 MiB high-water mark.

v0.1.285 — 2026-08-20

_"On every backend" was verified on one platform, and CI said so for four days._

v0.1.271 named the stack overflow, and its title says "on every backend". It was true on Darwin. On Linux it stopped the C backend compiling and the LLVM backend linking — every program, not an edge case — and parity has been red since the commit after it. Four consecutive days of failures, latterly hidden behind a stale version assertion.

Three platform-specific defects in one runtime block.

pthread_getattr_np is glibc's way to ask a thread for its stack, and glibc declares it only under _GNU_SOURCE. Without the macro the emitted C called an undeclared function, which clang 16 and later treat as an ERROR — and -w, which the parity harness passes, does not silence an error. The #define now comes before every header, which is the only place it works.

static char __lang_sigstack[SIGSTKSZ * 4] is a variable length array at file scope on modern glibc, where SIGSTKSZ expands to sysconf(_SC_SIGSTKSZ) rather than a constant. It is a literal 65536 now, comfortably above MINSIGSTKSZ on both platforms.

And the one that had no preprocessor to hide behind. The C backend picks between the Darwin pair and the glibc call with #ifdef; LLVM IR cannot, so the Darwin names went out on every target and nothing linked. They are declare extern_weak now and the call is guarded: on Darwin they resolve and the fault keeps its name, and elsewhere they are null, the bounds stay unknown, and the handler falls through to the plain segmentation fault it already reported for a fault outside the stack. That costs the NAME off Darwin and nothing else, and it needs no platform detection at emit time — so -ll output is still the same file wherever it was produced. A name derived from an assumed stack size would be wrong for any program linked with a bigger one, which is worse than no name.

What let it through is the shape worth keeping. The suite checks this feature by looking for stack overflow (recursion too deep) and sigaltstack in the EMITTED TEXT. Those assertions stayed green throughout, because a string is present whether or not the file it is in compiles. scripts/stack_overflow.sh runs a program that recurses until it dies and reads what it says, per backend, with the per-platform answers pinned rather than smoothed over. It is in CI.

platform C backend LLVM backend Darwin stack overflow (recursion too deep) stack overflow (recursion too deep) other stack overflow (recursion too deep) a plain crash, no name

Measured on Linux in a container, not inferred: the C backend now compiles and matches the interpreter on the first twelve parity programs, where before none of them built, and it names the overflow there for the first time.

v0.1.284 — 2026-08-19

_Generated inputs for the differential gates, and five NUL-length defects they found._

contrib/prop generates values; it does not compare them. A property test written with it is an ordinary parity case, so the other four backends are the oracle and there is nothing to commit as an expectation — the same shape as the browser dogfood's reftest, moved from pixels to values.

Three decisions, each a way this could have measured nothing. It does not use random_int: that builtin asks the host, five hosts would draw five sequences, and every line would report DIFF while the gate reported on itself. Values are a function of an index rather than a carried state, so a differing line in the diff already names its input — which is why there is no shrinker, the smallest reproducer is i and it is printed. Every intermediate stays below 2^45, because the interpreter's int is 63-bit and the compiled backends' is 64-bit.

The edge tables are not a draw. Every integer defect this suite has found sat on one of those values and a uniform draw reaches them with probability about zero, so a generator that only drew would be weaker than the hand-written gates it extends. NUL is in the byte pool on purpose.

Five defects on the first run, all one family

Code that was correct while a str ended at its first NUL, and silently wrong after v0.1.264 gave a str a length header.

Two recorded rather than fixed

Each pinned in its own case so it keeps being asked.

test/parity/prop_utf8.mere — UTF-8 character splitting. For "A" ++ chr 128 the interpreter says two characters and the three compiled backends say one, so utf8_at returns two bytes and codepoint_at then refuses. Index 0 is "A" and what follows cannot change that, so the interpreter is right. The span computation is prelude Mere, one source compiled by all four, which means the difference is under it — a separate measurement, not a guess to make while writing a test.

test/parity/llvm_loop_guard_global.mere — a loop whose bound is a top-level binding stops after one iteration on LLVM. All three ingredients are needed and each was removed in turn to check: the bound must be a top-level let and not a literal, the body must evaluate a try_or whose thunk calls a prelude function, and it must be recursive. A program folding this way would silently process the first element and report success.

The axes are kept apart

prop_int leaves multiplication out and prop_list leaves list_product out, both with the reason written down: their operands overflow, the interpreter wraps at 63 bits where the compiled backends wrap at 64, and a gate measuring the width axis while claiming the value axis reports the wrong one when either moves. codepoint_at moved out of prop_str for the same reason.

test_basic: "llvm: declares strstr" asserted how index_of is implemented rather than what it answers. It now asserts the memcmp and that strstr is absent.

Gates: unit 2527-0, parity 117-0 + failing 15-0 (5 declared divergences), ctest 14-0, selfhost 7-7, html_tokenizer ok.

v0.1.283 — 2026-08-18

_Two shadowing bugs, and a gate whose expectation was degenerate._

Both bugs had the same shape: the compiled backends resolve a name globally, and something shadowed it. The interpreter was right in both cases, which is what made them findable at all.

Q-045: a user binding that shadows a builtin the prelude calls

let show = fn (x: int) -> x + 1;
print (str_of_int (show 1))

Three lines, and it made the prelude fail to type — expected 'str', got 'int' at :485 for a program that never mentions the prelude — on all four compiled backends. The prelude's pow calls the show builtin. Not show-specific: str_len and list_len are each called three times in there.

Two independent causes, and the first hid the second.

The desugared program was typed against the accumulated environment. Since desugar_program turns every Top_let into a nested Let, the expression rebinds all of them itself — so passing the accumulated environment added nothing except the one thing it must not: a binding visible to declarations that come before it. It now types against an environment holding only what desugaring drops, which is externs.

That turned the error into a refusal from the monomorphiser, because uniquify_toplevel_shadows never saw the user's show as a shadow — a builtin is not a top-level declaration, so the first binding of that name kept it. It is seeded with the builtin names now, so the user's binding is renamed and references before it — the prelude's — still mean the builtin.

The seed subtracts the prelude's own top-level names: the prelude deliberately shadows ten builtins (pow, divmod, assert, …) and those keep the names they have always had.

Q-046: a parameter named the same as a top-level binding

uniquify_inner_fns_expr renames inner fn bindings that collide with a top-level name, and left Fun parameters alone. So a lifted inner function took no parameter for its captured handler at all, and its body referred to the caller's global of that name.

It was invisible while both had the same type — the wrong binding happened to fit — and surfaced as C that would not compile only when the types diverged. contrib/http2 carried a naming workaround for it; the parameter is renamed now, so that workaround is a comment about history rather than a rule.

Parameters get a different treatment from inner fns and the distinction is the point: an inner fn becomes a symbol and must reserve its name, a parameter does not and only has to not be mistaken for one.

Three test assertions were pinning a symbol name

§30.0 checked that a user-defined is_alpha shadows the builtin by grepping the output for int mu_is_alpha(. The fix renames it to is_alpha__v2, so they matched the prefix instead. Measured before changing: the compiled program answers true and the builtin answers false for the same input, so the behaviour under test was unaffected — the exact name only said it by accident.

The line-break gate was comparing against nothing

linebreak_conformance reported 19338 of 19338 cases differing. want.txt had 19338 lines and not one break mark in it: under this machine's LANG=ja_JP.UTF-8, awk 20200816 compares ÷ equal to × — collation, not bytes — so every mark became ×.

The implementation was right and the expectation was degenerate. It runs under LC_ALL=C now. It passes on GNU awk and under the C locale, which is why CI was green and a Japanese-locale machine was not — the environment difference to suspect first when a gate disagrees with CI. The data is ASCII plus those two symbols, so byte comparison was what was wanted all along.

Verified: 28 CI gates, runtest 2526/0, parity 110/0 + 15/0 (two new parity programs), selfhost_check all passed, host_matrix ok.

contrib — GraphQL introspection and validation — 2026-08-18

_No compiler change. contrib/graphql, two new gates._

Introspection is answered by the ordinary executor

__schema, __type(name:) and __typename. The introspection types are ordinary SDL, generated from graphql-js into introspection_sdl.mere and appended to the document's own definitions — so __Type is an object type like any other and field lookup, nullability, null propagation, list handling and enum coercion all apply to it unchanged. One line, and there is no second executor.

The SDL is generated and committed, like the Unicode and HPACK tables: the specification fixes every name, type and nullability, and a 200-line transcription has a mistake in it.

Introspection is cyclic, so one value has to be lazy. __schema.types lists every type, each type's fields name types, whose fields name types; a strict value cannot hold that and eager construction does not terminate. What bounds the expansion is the query — getIntrospectionQuery() asks for ofType exactly nine levels deep. So gvalue has one non-data arm, GTypeRef of gtype, computed when asked for: the only place in this executor where a field is computed rather than looked up.

The strongest check is not a comparison. Our introspection result fed to graphql-js's own buildClientSchema and printed must equal printSchema(buildSchema(sdl)). It holds exactly when our answer carries the whole schema, it is blind to field order (which the specification does not fix), and nothing transcribes an introspection result. It passed before the JSON comparison did, and both differences that then surfaced were real:

• A built-in scalar belongs to a schema only if something refers to it. The

oracle's type map for type Query { a: Int } is Query Int Boolean String and not the other two — Boolean and String because the built-in directives refer to them, which falls out of walking the appended SDL rather than being special-cased.

• graphql-js 17 keeps an argument's default in `a.default.value`, not

a.defaultValue. Reading the old field silently dropped @deprecated's default.

`includeDeprecated` defaults to false, and the standard introspection query passes true — so every gate section using it agreed while that was missing entirely. It took a hand-written __type(name: "Colour") { enumValues } to disagree.

Validation, and how a partial validator is gated

19 of the specification's 32 rules. The gateable part is the design:

Every error carries the name of the rule that produced it, and the harness compares the set of rule names against graphql-js running each of its 32 rules individually — the oracle classifying its own output. Not the error list, for two measured reasons: graphql-js returns errors in visitor order interleaved across rules, so a partial validator could never agree about anything; and rule names are about thirty identifiers from the specification's own section titles, small enough that a shared misreading is not a real risk.

Three failures, not one: rejecting what the oracle accepts (the worst — a false positive fails a valid request), missing a rule we claim, and missing a rule we do not claim (DOCUMENTED-GAP, and the rule must be listed). A gap-list entry that never fires fails the harness as stale.

The claim list is checked in both directions: every rule reported must be on it. Without that, dropping a rule from the list while still implementing it left the harness green — poisoning found it, because the list is otherwise consulted only for rules that were missed. A wrong list silently weakens every check that reads it.

The document and the schema are separate arguments, unlike the executor. ExecutableDefinitions is the rule that a document being executed must not contain type-system definitions, so a combined list makes every schema violate it — the first version reported every SDL type as "not executable".

What the harness caught: we rejected { __schema { queryType { name } } } because __schema / __type / __typename are provided by the schema rather than declared in it; is not defined **by** operation versus is never used **in** operation, two prepositions and one helper that put the wrong word in one of them; and a fragment cycle is reported once, at the first fragment in document order.

A harness bug worth naming

Comments inside a node script passed in a double-quoted shell string may contain neither a backtick nor a double quote — one is command substitution, the other ends the string. Both mistakes were made in consecutive edits. The second turned the comparison into a syntax error rather than a wrong answer, which is the good failure of the two.

contrib — HTTP/2 flow control and gRPC streaming — 2026-08-18

_No compiler change. contrib/http2, examples/grpc_hello.mere, and two gates._

Both directions of the flow-control window, SETTINGS_MAX_FRAME_SIZE, and gRPC methods that send or receive more than one message. grpcurl now gets server-streaming, client-streaming and bidirectional answers from a Mere server, and a 300 KB request and a 300 KB reply both go through.

The limits bite in an order, and the first one is not a window. Measured against a python h2 client before any of the code existed:

A fix that added window accounting without splitting frames would still have failed at 16385. The wbuf row is the one with no symptom at all: mem_copy_bytes is a memcpy into a bump arena that records no allocation sizes, so nothing below could catch it. Demonstrated with a sentinel — 32 bytes into a 16-byte allocation changed the byte after it and reported 32.

Flow control makes the writer a reader. A send whose window is exhausted has to consume the WINDOW_UPDATE that reopens it, so send_data contains a reader.

An export list is not a coverage list

H2.read_settings read each SETTINGS entry's 32-bit value at offset i+4 instead of i+2 — two bytes past every six-byte entry, so the last entry of any payload read off the end. Wrong for as long as the file has existed, and nothing called it: the writer had a parity section from the start, the reader was exported, documented, and never fed a byte, and the server's own comment said its peer's settings were "read and ignored". The first caller found it on the first connection, at byte 42 of a 42-byte payload.

Enumerating every export and counting call sites turned up a second accessor in the same state — H2.error_code, zero callers and zero coverage. It happens to be right. http2_parity.sh now feeds every payload accessor.

What poisoning found that valid traffic could not

• A well-behaved client cannot see a server that ignores its window. Poisoning

the check to "a billion bytes" left the section green: a client that acknowledges as it reads has already granted more credit by the time the next chunk arrives. The gate now has a rude client that advertises 8192 and stops reading.

• `SETTINGS` adjusts a spent window by the delta; it does not reset it — and the

two rules agree exactly when nothing has been spent. The SETTINGS now arrives mid-response, driving the window to -57343; negative is legal, and a reduction after credit was spent is the only way to get there.

• The SETTINGS branch of the window-wait loop recursed under a comment saying it

returned to its caller. A peer may reopen a stalled stream with `SETTINGS` alone, and this server would have waited forever. Found only because the delta poison was undetectable for the same reason.

• One rule was written twice. A WINDOW_UPDATE increment of 0 is a protocol

error; the frame loop ignored it and the window-wait loop failed on it. The wrong one was on the path every ordinary frame takes.

• `SETTINGS_MAX_FRAME_SIZE` could not bind. Its minimum is the default, so with

a 16384-byte write buffer min(peer, capacity) was always the capacity and reading the setting could not change the answer. The buffer is 65536 now, which makes the term live rather than deleting it.

Two wrong expectations, both the same slip

The boundary in the field is not the boundary on the wire: a 16384-byte reply field is 16393 bytes of DATA once the gRPC prefix, the protobuf tag and a 3-byte varint are added, so it already needs two frames. That got the frame-count expectation wrong, and later a window grant that left the server nine bytes short.

Also h2's local_settings.initial_window_size = ... is silently ignored before initiate_connection — the client advertised 65535, the server correctly sent 65535, and the harness blamed the server.

Streaming is the list having more than one element

The handler takes the request's messages as a bytes list and answers RpcOk, RpcStream or RpcErr; H2Server.unary adapts a one-in-one-out handler. There is no separate path for client-streaming. Interleaving is not supported and is said so rather than approximated: the handler runs after the request half-closes.

examples/hello.proto gained five methods and contrib/proto needed no change — stream was already parsed, and our descriptor for the new schema matches protoc byte for byte.

v0.1.282 — 2026-08-18

_The FFI byte arena gets a bytes bridge._

mem_to_bytes / mem_copy_bytes, the arena's two directions for data that may contain a zero byte — which mem_to_str cannot carry, because it stops there, and which every binary protocol has. Native and Wasm-component both, and scripts/socket_parity.sh requires the two to agree.

What it replaced. contrib/http2/server.mere was reading arena → hex → bytes (two characters per byte, three passes) and writing with `mem_set_u8` once per byte. The write is the one that mattered: a response is now one FFI call instead of one call per byte of it. Same shape as v0.1.222, where file_pwrite could not take a bytes and built one boxed int per byte.

The Wasm helper is a few instructions because the arena is linear memory there. The one thing to get right is that a bytes pointer points at the length, where a str pointer points at its data with the length at ptr-4; a comment says so, and poisoning the layout both ways is caught.

Two mistakes, and the second is the interesting one.

First, the definitions went where the rest of the arena lives — and the generated C said unknown type name 'mere_bytes', because b->data needs the complete struct and that block is emitted earlier. So they moved into the bytes runtime.

Then they were emitted there unconditionally, and __mem — the arena — is only emitted when a program declares an arena extern. Every program that uses bytes without the arena stopped compiling, which is most of them; proto_parity said so on the next run. Two independent conditions, and satisfying one is what made the other easy to miss.

The gate for that turned out to need one more thing: bytes_runtime was a top-level constant, evaluated at module-initialisation time — before any program is parsed — so a Hashtbl lookup inside it would have been false for every program that ever declared the externs. It takes the flag as a parameter now.

Poisoning found a coverage gap too: reading the length with i32.load8_u instead of i32.load passed, because on a little-endian machine the low byte of a length under 256 is the length, and every payload in the corpus was shorter than that. There are 255-, 256- and 300-byte payloads now.

v0.1.281 — 2026-08-18

_IEEE-754 bit access, in two halves because one would not fit._

float_bits_hi / float_bits_lo / float_of_bits, and f32_bits / float_of_f32_bits for float32. All five on all four backends, closing the last thing that stopped a protobuf double or float field from being generated.

The API shape was measured, not chosen. The obvious design is one accessor returning the whole 64-bit pattern. It does not work: read as a signed int64, a double's pattern exceeds this interpreter's native int — which is OCaml's, and 63-bit — for a large share of ordinary values. -1.5, 1e308, inf and nan all do. A single accessor would therefore answer differently on the interpreter than on every compiled backend, for a literal as plain as 1e308, and the honest options were a DIVERGE pin or a different API. Two 32-bit halves are each below 2^32, so there is nothing left to diverge about — and they are also exactly what a wire format wants, since it writes the bytes anyway.

f32_bits narrows to float32 with the backend's own double-to-float conversion, which is round-to-nearest-even. That matters more than it sounds: 1e308 has no float32, and the answer is +inf rather than a wrapped number. Writing that rounding by hand is the part nobody should have to get right twice.

contrib/proto/wire.mere gains put_double / get_double / put_float / get_float on top, so the split stays inside that layer and neither a caller nor a generated codec learns about it. The generator's refusal of double and float is gone, and scripts/proto_gen_parity.sh covers them — 25 schemas now, including 1e308, 1e-308, float32's maximum, and repeated floats, all byte-identical to protoc.

Two mistakes worth recording, both mine and both in the checking rather than the code.

The Wasm arm shifted with i64.shr_s. The top bit of a double's pattern is its sign bit, so an arithmetic shift sign-extends it and float_bits_hi (-0.0) came back as -2147483648 — a value that then compares as negative and divides the wrong way, on that backend only. It is i64.shr_u, and the comment now says why.

Finding it took two detours. First I read a stale binary: dune build 2>&1 | head -2 had exited on SIGPIPE, so the compiler under test was the poisoned one from a mutation run that a timeout had killed mid-restore. Then I "verified" the restore with grep -c 'i64.shr_u', which returned 1 — from a different, pre-existing occurrence elsewhere in the file. A check that cannot tell the two states apart is not a check; the verification is anchored to the arm now.

test/parity/float_bits.mere pins every class — normal, subnormal, both zeros, both infinities, NaN, the range ends — on four backends. NaN is checked through its bits rather than through ==, because == on NaN is false by IEEE and comparing it the obvious way reports a failure that is the comparison's own rule.

2026-08-18 — A protobuf code generator, and two branches nothing reached

_contrib/proto/gen.mere + examples/protoc_mere.mere: a .proto in, Mere source out. examples/grpc_hello.mere now uses it, and its hand-written codec is gone._

mere examples/protoc_mere.mere examples/hello.proto ../contrib/proto/wire.mere \
  > examples/hello_pb.mere

The codec in that example used to be a hand-written field walk and a two-line encoder. Both were correct, and both were a schema transcribed by hand — which is the thing a generator exists to stop.

scripts/proto_gen_parity.sh runs protoc's bytes through the generated codec and back: protoc --encode → decode_M → encode_M, byte-compared. 20 schemas. A round trip through the oracle's bytes catches more than it looks like, because a field the decoder ignores cannot be written back and shows up as a shorter byte string. The one thing it cannot see is a consistent swap of two fields holding equal values, so every field in the corpus has a distinct value.

Three representation choices, each forced by proto3 rather than chosen: a singular message field is a 0-or-1 list (message fields have explicit presence, so "absent" and "present but empty" differ — and it makes a recursive message expressible); an enum is an int and not a variant (a proto3 enum is open, and an unknown number has to survive a round trip); and a generated identifier never begins with the type name, because uppercase-leading is how this language recognises a constructor — M_get_a parses as one and is reported as an unknown constructor at its use site, naming something the schema author never wrote.

The encoder writes fields in field-number order, not declaration order, because protoc does.

Poisoning found two branches nothing reached:

1. The repeated zigzag and fixed families were not in the corpus. It had singular

sint32 and repeated sint64, so the repeated-sint32 path was generated and never executed — breaking it changed nothing.

1. protoc always writes packed, so the decoder's unpacked branch was never reached.

proto3 requires a decoder to accept both forms whatever the writer chose, and deleting that branch left the harness green. A decoder that only understands the encoding its own oracle emits works against exactly one kind of writer.

The second one needed input protoc does not produce, so the harness builds it — and the first hand-typed version had field 2's tag as length-delimited, which protoc rejected and the harness reported as its own bug, correctly. Hand-written test bytes are a transcription like any other, so they are computed from the values now. protoc is then asked whether the two spellings mean the same value rather than being told.

2026-08-18 — A .proto parser, and the bootstrap closing

_contrib/proto/parse.mere + contrib/proto/descriptor.mere: a .proto file in, a FileDescriptorSet out, byte-identical to protoc --descriptor_set_out across 72 derived files._

The bootstrap closes here, and that is why it is one harness rather than two. A descriptor set is itself a protobuf message, so the code that reads a schema is serialised by the code that reads wire bytes. If the varint encoder is wrong, this diff says so; if a descriptor field number is wrong, the same diff says so. One oracle checks both layers at once.

The comparison is bytes. A descriptor that decodes to the same text but different bytes is still a different descriptor to anything that hashes or caches it.

Three things were measured off the oracle before anything was written, and each would have been wrong from memory:

`descriptor.proto` is proto2, which reverses a rule the wire harness had just learned. A set field is written even at its default, so an enum value's `number: 0` appears on the wire — where proto3 omits a scalar holding its default and `v: 0` could not be swept at all. Same encoder, opposite rule, decided by the schema being encoded rather than by the encoder. `json_name` is not plain camelCase. my_field → myField is the easy one; a_b_c → aBC, trailing_ → trailing, __lead → Lead and num_2_x → num2X are the ones a guess gets wrong. The rule is "drop underscores, upper-case what follows each one". `type_name` carries a leading dot and is fully qualified, and a reference resolves from the innermost scope outward — so the same simple name is a different type at a different depth, and the wrong order still produces a well-formed descriptor.

The last of the 72 files to match differed by two bytes. rpc U (Q) returns (R) {} is not the same as rpc U (Q) returns (R); — the empty body sets MethodOptions to an empty submessage, so protoc writes 22 00 there and nothing for the semicolon form. Presence with no content is the whole difference.

The subset is refused, not skipped. oneof, map, import, option, reserved, optional, extend, group and proto2 are outside it, and protoc accepts every one — so the oracle cannot be asked whether they are wrong. The harness checks instead that each is refused by name, because a skipped construct produces a descriptor that is wrong where nothing looks. Getting that right needed two fixes the corpus found: an absolute type reference (.pk.M) is a different production from a name and needed its own reader, and a field option list met "expected ';'" — a syntax error about a file that is syntactically fine — until it was given a named refusal.

Ten poison mutations, none uncaught.

2026-08-18 — RPC statuses, and an expectation the wire corrected

_A gRPC handler can now fail._

bytes alone could not say "this failed", so an unknown method got a reply that looked like a success. A handler now answers RpcOk of bytes or RpcErr of (int * str), and a failure goes out as a status in the trailers — the request succeeded as HTTP and failed as RPC, so it cannot be expressed as a 4xx, and a failed unary call carries no DATA frame at all.

`grpc-message` is percent-encoded, which is neither optional nor cosmetic: the specification says so and grpc-go decodes it. Measured before implementing — caf%C3%A9 %25 done came back as café % done — so a raw % would have been read as the start of an escape.

And then the wire corrected the harness. The first expectation written for the raw trailer assumed a space and an apostrophe would be encoded. They are not: the rule is "bytes outside printable ASCII, plus % itself", the same as grpc-go's own encoder. The implementation was right and the expectation was a guess; the failing diff is what said which.

The DOCUMENTED-GAP that asserted the absence of statuses did its job on the way out: closing the gap made that assertion fail and report itself stale. Three routes are checked in its place — a method the schema declares and the server does not handle, a method that exists and refuses its input, and a message that needs encoding — and the python client now reads the raw trailers. That is the observation grpcurl cannot give: it prints the decoded message and the rendered code name, so whether the encoding happened is invisible there. Poisoning found nothing uncaught across five mutations, including lower-cased hex digits.

2026-08-18 — A GraphQL executor, and the one case out of 67 that mattered

_contrib/graphql/exec.mere plus scripts/graphql_exec_parity.sh against graphql-js's execute()._

The resolvers are the data. A field is resolved by looking its name up in the parent object, which is graphql-js's default. Both sides get the same schema, the same document and the same root value, so nothing about resolution is transcribed — two hand-written resolver sets would drift and the drift would look like an execution difference.

What that arrangement really exercises is null propagation, and it is why an oracle earns its place. A non-null field that resolves to null is not an error in that field: it destroys the nearest nullable ancestor. { nn } answers "data": null. An item error in [Int!] nulls the whole list with a path of ["ln", 1]. All of it was measured off the oracle before being implemented, because reading behaviour off a specification and reading it off a running implementation are different activities.

Every position is one of two things — GOk (value, errors) or GBubble errors — and the four cases in the specification fall out of those two constructors instead of needing exceptions the language does not have.

Of 67 corpus cases exactly one differed, and it was the interesting one. { o2 { nnx } } with o2: O! produced two errors: the real one about O.nnx and an invented one about Query.o2. The oracle produces one. When a non-null position is null because an error already propagated, no second error is raised — the check that would raise it is never reached, because the propagation went past it. The fix splits the job: raw completes a position with no absorbing, and complete decides what the position's nullability means. A list item goes through complete, so [O] nulls the item and [O!] nulls the list, which now falls out rather than being special-cased.

Poisoning the gate ten ways caught nine immediately. The tenth is worth recording as a coverage lesson: breaking the named fragment's type-condition check went unnoticed because the corpus only had the inline form. Two nearly identical branches, one of them unchecked. Three named-spread cases closed it, and the poison then failed as it should.

Error messages are compared verbatim — the specification does not fix the prose, so matching the reference implementation is the only way to compare them at all, and the oracle is pinned. locations are stripped from both sides: they need source positions the parser does not carry, which is a stated gap rather than an accident.

v0.1.280 — 2026-08-18

_A capture whose name has a dot in it._

An inner let rec that referenced a module-qualified name put that name into the closure's environment struct verbatim, so the C backend emitted

long long Wire.delimited;

and the generated C failed to parse. The error pointed at a line the program did not contain, which is the part that makes this worse than a refusal: the diagnostic was about generated C, not about the source that caused it. The interpreter was always correct, so nothing saw it until a dogfood compiled a wire-format decoder with Wire.delimited inside a field-walking loop.

The shape is narrow, and measuring which variants were affected is what located it. Four were fine — M.k at the top level, a top-level closure using it, that closure passed to a function, and an inner let rec capturing only its enclosing parameter. Only an inner let rec referencing a qualified name reaches the environment-struct emitter instead of being referenced directly.

The fix is that two paths now agree. The inner-LIFTED environment (__env_local->…) already ran capture names through flatten_module_dots; the anonymous-closure environment did not. Three sites — the struct's field declaration, the adapter's substitution, and the creation site that fills the environment in — now flatten too, with the substitution still keyed on the name as written because that is what Var n in the body says.

flatten_module_dots is the identity for a name without a dot, so every program that did not hit this emits byte-identical C. And every output that does change was previously invalid C — a dot in a field name has never been legal — so there is no program whose working output moved.

test/parity/module_qualified_capture.mere pins it on all four backends, including the variants that were not broken, so a future change cannot fix one path and regress the other.

2026-08-18 — A gRPC server in Mere, and two bugs loopback was hiding

_contrib/http2/server.mere plus examples/grpc_hello.mere. grpcurl asks a Mere server for a greeting and gets one._

$ grpcurl -plaintext -protoset hello.protoset -d '{"name":"mere"}' \
    127.0.0.1:50079 hello.Greeter/SayHello
{
  "message": "hello mere"
}

Everything under that line is Mere: the protobuf wire format, the HTTP/2 framing, HPACK, and the connection. TLS is absent by measurement rather than oversight — h2c is what grpcurl -plaintext speaks, 24 literal bytes and no negotiation.

scripts/grpc_parity.sh is the first harness here that does not compare bytes. Every layer underneath already has a byte-level gate; none of them answers whether a client that knows nothing about any of it gets a reply it recognises. Two clients, because they ask different questions: grpcurl (Go) over four connections including an empty proto3 request, and a python h2 client making three requests on one connection — the case grpcurl cannot express for a unary method, and the one that catches a per-stream HPACK decoder.

Poisoning it found two bugs that every other section passed:

1. Removing the frame reassembly changed nothing. On loopback a request arrives

in a single read, so a server that parses whatever one read handed it works. The comment in server.mere had said reassembly "is not a simplification, it is a bug that happens to pass on a fast loopback" — and the harness proved the comment right by failing to catch its removal. The python client now sends one request split every seven bytes, so the 9-byte header itself straddles two reads.

1. Removing the SETTINGS acknowledgement changed nothing, because neither client

blocks on it. The client now asserts the ACK arrives.

Both are the mirror of the dead guards found in frame.mere yesterday: there, code that nothing reached; here, behaviour that nothing observed.

Two harness bugs were worth more than they cost. The readiness check waited for the port by connecting to it — which the server counts, since it serves a bounded number of connections and then exits, so the probe ate one and the last real call got "connection refused" while the harness blamed the server. It waits for the server's own "listening" line now. And the unknown-method section printed its DOCUMENTED-GAP without calling anything: a claim, not a check. It calls a method the schema declares and the server does not handle, and requires the documented answer.

One compiler bug came out of writing the example and is recorded rather than fixed: an inner let rec that references a module-qualified constant makes the C backend emit the qualified name as a struct field — long long Wire.delimited;, which is not valid C. Six lines reproduce it, the interpreter is correct, and the error names generated C rather than the program that caused it.

2026-08-18 — HPACK, and three ways a gate can pass without checking anything

_contrib/http2/hpack.mere plus a generated table and a seven-section gate. The implementation went green on the first run; poisoning it is what produced the interesting part._

What had to be complete was measured. grpcurl 1.8.8's first HEADERS frame on a real connection uses static-table indices, Huffman-coded literals and seven dynamic-table insertions — so the decoder is complete (integers, both string forms, all five instructions, eviction) while the encoder is trivial: literal, new name, no indexing, no Huffman, which RFC 7541 permits and which a real client was confirmed accepting end to end. That asymmetry is why a gRPC server is reachable without writing a Huffman encoder.

The dynamic table is connection state and is threaded through the API rather than hidden in a global, because one decoder per connection is correct and two is not, and a parameter makes that visible at the call site.

The tables are generated from the same library the gate uses as its oracle, which is a hole a differential test cannot close: a shared transcription error is invisible. So one section decodes a header block captured from grpc-go 1.57 — a third implementation, in another language, that never saw either table. Nine header names and the table's own accounting come back matching.

Then the gate was deliberately broken, nine ways. Six were caught immediately. The other three were the point:

1. Valid input does not test a refusal. Removing the Huffman padding check

changed nothing, because well-formed blocks have well-formed padding. Nine malformed blocks now exercise the refusals — the same lesson the GraphQL reject-list taught, arriving again in a different file.

1. "Does it refuse" and "does it say what was wrong" are different questions.

Removing the index-0, EOS and string-length checks still refused, further downstream, with a message about something else — so the gate stayed green while three named diagnostics had been deleted. Each malformed case now asserts a substring the refusal must contain. That couples the harness to our own wording, which is the acceptable direction; coupling it to the oracle's would be brittle for no gain.

1. A check whose input never arrives passes. The case file was written with two

columns while the reader expected three, so every expectation was the empty string and grep -q "" matched every message. An empty expectation is now a failure in itself — and so is a reject-list that checked zero cases, which is the rule the builtin matrix learned in another form: a gate reporting ok for no cases cannot be told apart from one that did not run.

One line survives poisoning on purpose. len2 < huff_min_len is a fast path, not a check — huff_count already answers 0 below the minimum length — and it is labelled so the next reader does not have to work that out. The contrast with the lshr mask deleted yesterday is deliberate: that one was a guard that could not fire, this one is an optimisation that provably cannot change an answer.

2026-08-18 — GraphQL's type-system half, and HTTP/2 frames

_contrib/graphql grows SDL; contrib/http2/frame.mere arrives with a gate against hyperframe. Both gates were then deliberately broken to see whether they could fail, and both had blind spots._

SDL — schema / scalar / type / interface / union / enum / input / directive, with descriptions, implements A & B, argument definitions and defaults. The derived corpus goes from 153 to 366 documents and the round-trip covers all of it unchanged, because graphql-js's print handles type-system definitions too.

Then the half that was missing: everything so far fed valid documents, and a parser that accepts anything passes all of it. A reject-list of 37 documents the oracle rejects found six real defects on its first run:

`{ }`, `type T { }`, `enum E { }` and `input In { }` were all accepted. Every delimited list in this grammar needs at least one element except the two that are values — `[]` and `{}` are legal, `{ }` as a block is not. One helper that names the production replaced seven call sites that each returned `[]`. 007 was accepted (an IntValue may not have a leading zero) and so was 1. (a fraction needs a digit). The lexer now also refuses a number followed by a digit, a . or a name start, so 1.2.3 is an error rather than two tokens.

A harness defect came out of the same exercise: set -e plus a crashing subject made the script stop mid-run having printed no verdict, hiding every later section. The subject now runs through a helper that never aborts and names the section it failed in. set -e stays for the preflight, where a missing oracle should stop everything.

Type-system extensions (extend ...) are refused rather than mis-parsed — reading extend type T as type T would produce a tree that says something the document did not — and the refusal is asserted, so the day extensions land that section fails and says the assertion is stale.

HTTP/2 frames — the preface, the 9-byte header, SETTINGS / WINDOW_UPDATE / RST_STREAM / GOAWAY payloads, and the gRPC message prefix. hyperframe is the oracle: 50 frames byte-identical on encode, the same 50 compared on fields on decode, with the sweep crossing type × flags × stream id × payload size (0, 1, 2, 255, 256, 16383, 16384 — every length-encoding boundary).

One byte has two independent confirmations, which is the only kind of agreement worth having: an empty SETTINGS frame serialises as 000000040000000000, and that is byte-for-byte what grpcurl 1.8.8 was observed sending on a real connection. hyperframe and grpcurl never met.

Poisoning that gate found two things the sweep could not reach:

The `lshr` mask was dead. Every shift here is immediately masked with 255 to extract a byte, and the bits an arithmetic shift copies in sit above bit 7, so a logical shift gives the same answer. Removing the mask changed nothing, which is the definition of dead code. It is not dead in `contrib/proto`, where the shifted value is the loop variable and a negative int64 would never terminate — the contrast is now written down in both files. The writer's stream-id mask was never exercised, because every stream id in the sweep already has the reserved bit clear. A section now writes 0x80000001 and requires the same frame as stream 1. The decode direction was already covered: 0x80000001 must read as 1, not 2147483649.

Both are the same shape — a guard nothing reaches is indistinguishable from a guard that is wrong.

2026-08-18 — Two protocols: the protobuf wire format, and GraphQL documents

_contrib/proto and contrib/graphql, each with a gate against somebody else's implementation._

`contrib/proto/wire.mere` — the Protocol Buffers wire format, both directions, below any schema. scripts/proto_parity.sh holds it to protoc's bytes: one message containing every wire type compared whole, swept value lists crossing every varint length boundary, the int64 edges, and protoc's own bytes read back and rewritten. Interpreter and C backend both.

Three things the harness had to be taught, each by being wrong first:

`bit_shr` is arithmetic, so a negative int64 shifted right never reaches zero and the encoder loops forever. Every right shift here is masked. 0 cannot be swept. proto3 omits a scalar holding its default, so protoc --encode answers the empty string for v: 0 while a schema-less layer writes 0800. That is a question one layer up, not a wire-format disagreement. The zigzag bound is half the varint bound, because zigzag doubles its input.

And one thing that is pinned rather than fixed: the interpreter's int is 63-bit (OCaml's native int) while every compiled backend's is 64-bit, so above 2^62 the same program gives different answers — bit_shl 1 62 is negative on the interpreter and bit_shl 1 63 is zero. Those are recorded as a DIVERGE pin, not a tolerance, so the day the interpreter becomes 64-bit that section fails and says the pin must be retired. Related: an integer literal above 2^62−1 cannot be written at all — it dies with an uncaught Failure("int_of_string") — so the edge values in the harness are computed from 2^62−1 instead. This is the int axis of the open question about builtin parity at particular values, and it is the same shape as the float axis before exponent literals landed in v0.1.260: the reason it was not measured is that it could not be written.

`contrib/graphql` — lexer, parser and printer for executable documents (operations and fragments; SDL is a separate grammar and is not here). scripts/graphql_parity.sh checks it against graphql-js by sending our output back through their parser:

theirs: print(parse(D)) -> A     ours: print(parse(ours(D))) -> B     assert A == B

print is a function of the AST alone, so equality holds exactly when the parses agree — and nothing transcribes an AST. The alternative, serialising both trees into a shared format, needs a serialiser for the oracle's tree that can hold the same misreading as the parser it checks; a differential gate that shares a bug with its subject reports agreement. The corpus is derived rather than written down: every value kind × every position admitting a value, every selection form, every operation shape, nested type expressions. 153 documents.

The gate was then deliberately broken to see whether it could fail. Dropping every directive in the printer: caught. Dropping field aliases in the parser: caught. Making the lexer call every number an IntValue: not caught — the printer emits a numeric literal's lexeme unchanged, so IntValue "1.0" prints 1.0, the oracle re-parses it as a FloatValue, and the two printed documents agree. A round-trip is blind to any distinction that prints identically. A fourth section now asks for the kind directly, and it is the one place that transcribes anything from the oracle's tree — a two-word vocabulary.

The printer refuses a block string whose value would not survive re-parsing rather than emitting an ordinary string: the dedent rule is applied again on the way back in, and downgrading it would round-trip the text while losing block: true from the tree — a wrong answer wearing the face of a parser bug.

Both gates are in CI, both run under dash before being put there, and both oracles are pinned and printed (protoc 27.3, graphql-js 17.0.2).

v0.1.279 — 2026-08-17

_The refusals that were left, and three bugs they walked into._

The enumeration's tail: bytebuf_get / bytebuf_set, write_file_bytes's byte range, len on a value that is not a list, and comparing two functions. Asking them turned up three things that were not about refusals at all.

A program that used a ByteBuf and no `bytes` value did not compile. The C backend emits the bytes runtime when bytes_used is set, and freezing a ByteBuf calls __lang_bytes_alloc — the comment above the emit even says so, so the order of the two runtimes had been thought about and the dependency had not. Third time a use-gate has emitted a call to a function it did not emit.

`len (Some 1)` emitted C that dereferenced `payload.Cons` on an option. The guard for the cons-walking branch asked whether the program contained Nil and Cons anywhere, not whether this type has them, so any program that also mentioned a list took that branch for every polymorphic variant. It asks the type now, and a type with no length is a clean codegen refusal naming the alternatives.

Comparing two functions was a runtime failure on the interpreter and invalid C on the compiled backends — == between two closure structs does not compile. The type is known where the comparison is written, so the typer answers there now, with the interpreter's own words.

The refusals themselves: ByteBuf's index failures and the byte-range check both printed and called exit(1), so try_or could not take them and the program stopped where the interpreter carried on. They are catchable failures now, with the messages they already had. test/parity/bytebuf_edges.mere is the gate — interp + C, since bytes/ByteBuf is those two backends by scope.

Also: __lang_str_count still returned i32 on LLVM after v0.1.276 widened it on C and Wasm — a count past two billion came back negative. The sweep missed exactly one backend of the three.

v0.1.278 — 2026-08-17

_The last of the oracle's refusals._

The bytes value has the same index surface as vec, and it had all the same problems one slice later than vec did:

random_int on the Wasm host accepted any bound. There is no RNG wired there yet, which is a documented limitation — but "no RNG here" and "any bound is fine" are different statements, and the second one is a wrong answer. The bound is checked now even though the value it returns is still a deterministic zero.

That closes the enumeration started in v0.1.276: every refusal the interpreter raises is now raised by all four backends, with the same words, catchable in the same way. test/parity/refusals.mere covers the caught side and there are 15 programs in test/parity/fail/.

v0.1.277 — 2026-08-17

_Finishing the enumeration, and two things it turned up on the way._

v0.1.276 asked the oracle's refusals and fixed the nine it had probed. This is the rest of that list.

`bool_of_str` answered false for anything that was not "true" — on all three compiled backends, with a comment in the C source stating that this "matches interp". The interpreter has never done it: it refuses any word that is not one of the two. A claim in a comment is not a check.

`float_of_str` was three different wrong answers to the same program:

atof reads a prefix and has no way to say "that was not a number"; on Wasm the host's parseFloat has the same problem plus a smaller idea of what a float is, and its failure value is NaN — which is indistinguishable from the float nan, so nothing could be refused there at all. Validity now comes back from the host separately, because one return value cannot say both.

The oracle is float_of_string (String.trim s), which accepts rather more than a decimal point: hex floats, inf / infinity / nan in any case, signs, and underscores as separators (1__0.5 is 10.5). All four backends now agree across all of it, and test/parity/refusals.mere checks fourteen spellings.

Two things the new gate found on its way in:

• str_unescape allocated its buffer for the input's length, and every escape

makes the output shorter — so the length header said the wrong thing, and str_len (str_unescape "a\nb") was 4 on C and LLVM where the interpreter and Wasm said 3. Printing the value wrote a trailing NUL, which is invisible in a terminal. It took a case that printed an unescaped string to see it.

• The Wasm host's worker env is a second import table for the same module, and

adding an import to the module without adding it there makes instantiation throw inside the worker — after which the main thread waits on a generator that will never yield. That is a hang, not an error: it cost twenty minutes of a parity run before I looked at the process list.

v0.1.276 — 2026-08-17

_Asking the question mechanically, after finding the same shape by accident twice._

v0.1.274 found string sizes narrowed to 32 bits; v0.1.275 found indices narrowed the same way, one layer down. Both were found by a probe that happened to ask. So the third time the question was asked from the other end: every refusal the interpreter can raise, enumerated from eval.ml, checked against what the compiled backends do with the same input.

Nine diverged, and always in the same direction — the compiled backends had no check at all and returned whatever the byte or pointer arithmetic produced:

Every one is a value a program can produce by accident and then keep computing with. All four backends now raise the interpreter's own failure, with its exact words: chr: 256 out of byte range [0, 255], ord: expected single-char str, got length 2, str_repeat: negative count -1, str_unescape: unknown escape '\q'. test/parity/refusals.mere is the caught side; uncaught_chr_range and uncaught_ord_length join the uncaught ones.

The same sweep turned up three more narrowings and closed them: str_count's result, strbuf_len's result, and sleep_ms's argument were all int.

A note on method: the harness for the first measurement had a bug of exactly the kind these slices keep finding — when a backend failed to compile, the shell variable kept the previous backend's output, so one column of the table was a copy of another. It was caught because random_int has no LLVM lowering and the "LLVM" column reported values anyway. A measurement that cannot fail loudly is not a measurement.

v0.1.275 — 2026-08-17

_An index the collection does not have — answered, for years, with an element._

let v = vec_new ();
let _ = vec_push v 10;
let _ = vec_push v 20;
vec_get v 4294967297     // interp: refuses.  C, LLVM, Wasm: 20.

An index is a Mere int, sixty-four bits of it, and every compiled runtime took one as thirty-two. The bounds check then ran on the truncated value, so 4294967297 was checked as 1 and a two-element vec cheerfully returned its second element and exited 0. All three compiled backends agreed with each other, and none of them agreed with the interpreter. No test caught it because every index in every test was small — the same blind spot the string widths had in v0.1.274, one layer down.

Out of range was its own mess, three ways at once:

Every backend now raises the interpreter's own failure, which names both numbers at full width: vec_get: index 4294967297 out of bounds (len = 2). On C and LLVM the message is built with snprintf — LLVM's needed its varargs signature spelled out at the call site, or the arguments arrive through the wrong ABI slots and the message prints numbers nobody passed. Wasm has no snprintf, so it builds the sentence from interned parts with its own show_int and str_concat.

test/parity/index_edges.mere is the caught side (nineteen positions, in range, one past the end, negative, backwards, and past what 32 bits can name); uncaught_vec_index, uncaught_char_at_index and uncaught_substring_range are the uncaught side.

What it found immediately. The Ruby subset's utf8_cp decodes a sequence's continuation bytes before checking they exist, and on binary data — where any byte ≥ 0xC0 looks like a lead byte — the last one sends it past the end of the buffer. It had been reading out of bounds on every SHA-1 call for as long as digest has existed, and nothing showed: the read returned the NUL terminator and the value was discarded, since only the sequence length is used. A check that refuses is how a read like that stops being invisible.

v0.1.274 — 2026-08-16

_A string the machine cannot hold, and two backends that answered with a number._

Asking for str_repeat "ab" 500000000000000 used to produce four different things, and the two most used backends produced a plausible integer and exit 0:

Two defects compounded to make that possible.

Mere's int is 64-bit; the runtimes serving it were not. The count reached C through an int parameter and LLVM through an explicit trunc i64 ... to i32, so a 64-bit value arrived as its low 32 bits and asked for a string the program could actually have — a different string, returned without complaint. The same narrowing was in str_len ((int) __lang_str_size), substring's indices, str_index_of's result and utf8_len's count. A 2.15GB string — one byte of address past what a 32-bit offset can name — reported a negative length and a negative match offset. Every string in every test until now was small, so the axis had never been asked.

The allocator never read what malloc answered. When it said no, the next line wrote through the null it returned, and the program died by segfault — the nameless death v0.1.271 removed everywhere else. It is a named, catchable failure now, on both backends, and the region's doubling no longer wraps size_t on its way to a request bigger than half the address space.

On Wasm the memory is a fixed 64MB and nothing grows it, so exhaustion arrives as an out-of-bounds trap. The host used to exit 1 in silence for every trap that was not fail; it now names that one out of memory and prints the engine's own words for anything else, so no trap is anonymous.

Gated two ways. test/parity/fail/uncaught_out_of_memory.mere holds all four backends to the same sentence on a request no allocator can satisfy — it is refused instantly, so it costs nothing. scripts/bigstr_check.sh is the 2.15GB measurement, deliberately not in the parity run: it costs 4.3GB of resident memory per backend, and a gate too expensive to run is one people stop running. The Wasm backend is not in it, because a 2GB string is not a value that backend can hold — asking it would measure the memory limit rather than the width.

v0.1.273 — 2026-08-16

_A gate that cached the thing it was testing._

scripts/selfhost_check.sh compiles a set of programs with both compilers -- the OCaml one and the self-hosted Mere-in-Mere one -- and diffs what the two binaries print. Run yesterday it reported 7 failures out of 7, every case, with the self-host side empty: the reading a person would take from that is that the self-hosted compiler is completely broken.

It was fine. The gate builds the self-hosted compiler into /tmp/selfmere.wasm only if that file does not already exist, and the copy sitting there was three days and one ABI change old -- built before str grew its length header. The gate was testing a compiler nobody had asked about.

CI never disagreed. A fresh runner starts with an empty /tmp, so CI always built the current compiler and always passed. The same commit was green on the machine nobody looks at and red on the machine someone is working on, and the red one was the wrong answer.

It builds every run now. The whole build is 260ms -- there was never enough here to cache. A sweep of the other gates for the same shape (reuse an artifact if present) finds none.

The failure report is also bounded now. When this failed it wrote 18MB of WAT into the terminal, and the part worth reading -- that one side was empty -- was the first line of it. Ten lines of each side and the paths, so the rest is one command away.

v0.1.272 — 2026-08-16

_Q-032 closed: the Wasm backend learned to unwind, and the last pin came down._

fail on this backend has nothing to unwind with. It sets a flag, returns a sentinel, and the try_or at the boundary reads the flag -- so the failure was caught, but everything between the fail and the catch still ran. A body that pushed three strings and failed after the second pushed the third here and nowhere else. That one line was the parity suite's last DIVERGE pin, standing since v0.1.246.

Unwinding, written out by hand: after a call, ask whether the callee failed and return at once if it did. The check goes in at emit_instr -- the one place every call passes through -- rather than at each emission site, which is how the sites that were forgotten in earlier sweeps would have been forgotten again. A return_call is exempt: it is a tail call, the frame is already gone. So is try_or's own call to the thunk, which is the frame that must not propagate.

The interesting half is the second question: which calls need to ask. A callee that cannot reach $__lang_fail cannot have set the flag, and the assembled module can prove that where the emitter could not -- so a pass over the finished module computes reachability and takes those checks back out. On a self-hosted compile that is 2,524 of 3,722 call sites:

Everything unknowable keeps its check: indirect calls (the callee is a table index), imported functions (the host can re-enter the module), and any callee without a definition in the module. Removing a needed check would be a silent wrong answer, so every doubt resolves toward keeping it.

scripts/parity.sh also learned to fail on a stale pin. A pinned divergence that starts matching used to pass quietly, because a matching case never reads its .expected file -- the declaration would have stayed on disk saying something that had stopped being true. That is the exact failure the pin mechanism exists to prevent, so the gate now names the file and asks for it to be deleted. It is how this slice found out it was done.

v0.1.271 — 2026-08-16

_The failure that had no name._

Recursion deeper than the stack is the most common way a Mere program actually dies -- three of this week's findings were exactly that -- and until this slice it was the one failure the language never said anything about. Four backends gave four answers, and the two most used gave none:

The compiled backends carry a SIGSEGV/SIGBUS handler that runs on a stack of its own -- the stack that just overflowed has no room left to run a handler -- and it claims a stack overflow only when the faulting address is near the stack. Anything else keeps its own name: a segfault from some other cause is still reported as a segfault, because a diagnostic that guesses is worse than one that does not exist. The bounds are read from the thread rather than assumed, which is what makes the answer right for a program linked with a bigger stack -- a 512MB one, as the Ruby subset uses, overflows far below any 8MB guess and would otherwise have been misnamed.

The interpreter's limit is declared, not discovered. OCaml 5 grows the main fibre's stack by copying it, so finding the host's real ceiling costs 68 seconds and gigabytes of copying, and the depth it finds -- around forty million frames -- is two orders of magnitude past anything a compiled backend can reach. A program that recurses that far has already failed everywhere else. The interpreter now stops at 1,000,000 frames (MERE_MAX_DEPTH to move it) and says the same sentence in about a second. The count comes back down with the stack it was counting, so a program that catches a failure inside a loop does not drift upward into a depth it is not at.

test/parity/fail/uncaught_stack_overflow.mere is where the agreement is checked rather than claimed: 8 failing-program cases now, all four backends matching on exit status, prior output and message.

This also corrects v0.1.270's closing paragraph, which named the region as the cause of a crash nobody had measured. It was the stack.

v0.1.270 — 2026-08-16

_The other helper that could not survive a long list, and a sweep that says there is no third._

list_filter was fixed two slices ago for rebuilding its result through the return path. The obvious next question is whether it was the only one, and asking it the lazy way — grep the prelude for a self-call wrapped in a constructor — turns up exactly one more: `list_sort_insert`, which walks to the insertion point through Cons (h, list_sort_insert cmp t x) and so recurses once per element it passes. Inserting into a 50,000-long sorted list overflowed the stack on the compiled backends.

It accumulates and reverses now. The same sweep over the whole prelude afterwards finds no remaining wrapped self-call: list_map, take, concat, flat_map, zip, append, the merge-sort quartet and the utf8 helpers were all already in that shape, and the two that were not are both fixed.

Worth separating from the depth question: each list helper handles a 50,000-element list on its own, and a program that builds several such lists at once stops earlier on the compiled backends. That is the region running out, not the stack -- a different axis, and one this measurement deliberately does not mix in.

Corrected in v0.1.271. That last paragraph is a guess written as a finding: the crash was never measured, only named. It is the stack. The same program runs to completion under ulimit -s 65520, and under v0.1.271 it says so itself. The region was not involved.

v0.1.269 — 2026-08-16

_A match arm is a tail position too, which is where nearly every recursive list helper's tail call actually lives._

v0.1.267 gave the LLVM backend a notion of tail position and emitted musttail, and the measurement that immediately followed it — the collection value axis — said list_sum over a list still died at 100,000 there while C was fine at 200,000. The reason was narrow: only `If` had been made tail-aware. Every recursive helper in the prelude is written with match, so its tail call sat in an arm that branched to a join and phi'd — the one shape musttail cannot take.

An arm in tail position returns now, exactly as a tail-position If branch does. list_sum runs at 500,000 on LLVM, and a program that puts a 300,000-element list through every list helper — len, sum, rev, map, filter, fold — gives the same answers on the interpreter, C and LLVM.

The lesson is about where the measurement pointed. "Tail position" sounded like one concept and was implemented as one construct; the gate written an hour later found the other construct by asking a question that had nothing to do with tail calls.

v0.1.268 — 2026-08-16

_A missing map key is catchable everywhere, and list_filter survives a list longer than the stack._

The third value-axis parity case — after the integer widths and the string edges — asks about collections: the empty ones, the single-element ones, a key that is not there, and a list long enough to leave the small cases behind. It found two.

A missing map key was not catchable on any compiled backend. map_get wrote its own diagnostic and then abort()ed (C, LLVM) or executed unreachable (Wasm), so try_or (fn () -> map_get m k) d answered d on the interpreter and died with 134 or 1 everywhere else. It goes through the same failure path every other fail uses now: caught, it returns the default; uncaught, all four print the same sentence and exit 1.

`list_filter` recursed to the length of the list. Every other list helper in the prelude accumulates and reverses — list_map, list_take, list_concat, list_zip, list_append all do — and this one built Cons (h, list_filter t p), so filtering 100,000 elements overflowed the stack on a backend where mapping them did not. It accumulates now.

The case is sized at thirty thousand deliberately. Past that the axis stops being about values and becomes about stack depth, which differs per backend and per operation — list_sum alone survives 80,000 on LLVM and dies at 100,000 while C is fine at 200,000. A value gate that also measured the stack would report the wrong thing whenever either moved.

v0.1.267 — 2026-08-16

_The LLVM backend's tail calls are musttail, so a loop written as recursion runs in constant stack there too._

The C backend learned this in v0.1.230 — self tail calls became a goto — and the same measurement was left standing against LLVM: ten million iterations died with SIGSEGV at `-O0` while C ran them in constant space, and the emitted IR carried no tail marker at all. The note recorded it as measured rather than assumed, and said what the fix would cost: musttail is the marker LLVM guarantees regardless of optimisation level, but it requires the call to be immediately followed by a `ret` of its result, and this backend had no notion of tail position.

It has one now. emit_expr carries the same tail-position flag the C backend uses, cleared at entry and restored only for the sub-expression that stays in tail position. An If in tail position returns from each branch instead of joining through a phi, which is what puts a tail call next to its ret. A call in tail position whose prototype matches the enclosing function's is emitted as musttail.

Ten million iterations now run at -O0, and so does mutual recursion between two functions. MERE_NO_TAIL_CALL=1 turns the transform off, the same escape hatch MERE_NO_TAIL_LOOP gives the C side — "is it this change?" stays a one-variable question.

v0.1.266 — 2026-08-16

_The string values four backends were never asked about, and the two answers that were wrong._

A new parity case walks the axes the open question about builtin parity names next to the width one it already closed: the empty string, an index that is not inside the string, and a string big enough to leave the small cases behind. Every string probe in the suite until now used a literal a human types in the middle of the range, so a helper that divides by a length of zero, or reads one byte past the end, answered every question it was asked.

It found two, both on LLVM and both from this week's header migration:

• `str_repeat s 0` allocated its empty result directly, without a header — the

one case that computes no length, and so the one the mechanical conversion missed. str_len of it read whatever preceded the allocation.

• `str_trim` walked a pointer into the string and then asked for its length.

An interior pointer has no header of its own. This is the same bug the Wasm backend had in v0.1.262 — invisible on LLVM until today, because there was no header there to read wrongly.

The second one is the interesting one: the same defect existed in two backends, written years apart, and the gate that found the first could not see the second until the representation changed underneath it.

v0.1.265 — 2026-08-16

_What fail hands back on Wasm is an empty str, so the code it cannot unwind past survives to reach the try_or._

Wasm has no unwinding here: fail sets a flag and returns, and the callers check the flag on the way out. The value it returned was 0 — which is not an address. A consumer sitting between the fail and the try_or that treated it as a str read the length header at -4 and trapped, so try_or (fn () -> str_len (fail "b")) (-1) died with no output where the interpreter, C and LLVM all answered -1. Which of the two happened depended on what the consumer did with the value, which is the worst property a failure can have.

The sentinel is an interned empty str now. An empty str is a valid answer to every string operation, so the code between the fail and the catch survives, and the try_or default comes back on all four backends.

This does not make fail unwind, and the parity case still pins the difference that remains: statements after a fail in the same body still run, so a buffer that three pushes wrote to reads "onetwothree" there and "onetwo" everywhere else. That is the open half of the question, and it is where the pin now points.

v0.1.264 — 2026-08-16

_The LLVM backend's str carries its length, and the last pin comes off._

Its str was a bare pointer: str_len called strlen, == called strcmp, and literals were plain [N x i8] globals. So on that backend a zero byte was not a byte — str_len (chr 0) answered 0 against 1 everywhere else, and chr 0 == "" was true. The open question about it named the consumers: percent-decoding a URL and decoding Shift_JIS both produce arbitrary bytes, and LLVM alone gave a different answer for them.

It now lays a str out the way the other three do — [i64 len][bytes][NUL], value at byte0. Literals are { i64, [N x i8] } constants and the value is a constant getelementptr into the second field; every runtime helper that builds a string allocates through __lang_str_alloc; the ones that only learn their length at the end (replace, trim, unescape) call __lang_str_finish to write it. Strings that arrive from libc — asprintf for show, snprintf for floats — are copied into a header by __lang_str_of_cstr at the boundary. str_len, ==, str_compare and print all read the header, so a NUL is a byte on all four backends.

The trailing NUL stays. Everything else in this runtime still hands pointers to libc, and keeping the terminator is what let the migration be incremental rather than a rewrite.

Two things repeated from the Wasm slice a day earlier, which is worth writing down: the allocator had to be emitted unconditionally (it lived with the concat helper, so a program that only showed a value referred to a function that was not there), and every internal message global that gets concatenated — the fail prefix, the int_of_str message, the show constants — needed a header of its own.

nul_in_str has no pinned divergence left.

v0.1.263 — 2026-08-16

_The self-hosted Wasm backend carries the length header too, so the host can stop guessing._

The previous slice found that print on Wasm wrote up to the first NUL and could not do otherwise: the JS host runs modules from both compilers, and while the OCaml backend lays a str out as [i32 len][bytes][NUL], the self-hosted one still emitted the pre-header representation — a bare NUL-terminated buffer — while stamping the same ABI number as the compiler that carries a header. A number that says "you may read the length at ptr-4" is worth nothing if half the modules do not have one.

So the self-hosted backend lays strings out the same way now: literals carry a four-byte header in the data section, $__lang_strlen reads it instead of scanning, and every helper that builds a string — concat, substring, repeat, char_at, chr, strbuf_to_str, unescape, show_int/bool/str — allocates through one place that writes it. The digit buffer show_int fills right-to-left is copied into a str that has room for a header in front, the same answer the OCaml backend reached.

With both compilers agreeing, the host reads by length, and print on Wasm writes the whole value: the nul_in_str parity case needed a Wasm pin for exactly one slice. LLVM keeps its pin — its str is a bare pointer with no header anywhere.

Two things fell out of doing it. $__lang_str_alloc had to be emitted unconditionally rather than with the length helper: a module that showed a bool without measuring a string referred to a function it did not define. And the emitted module grew 17 bytes, which the size guard on the self-hosted codegen reports — four bytes per literal is the cost of a length that does not have to be searched for.

v0.1.262 — 2026-08-15

_An interior pointer has no header, and str_trim asked one for its length._

Chasing the Wasm half of the previous slice found something smaller and real. str_trim skips leading whitespace by walking a pointer INTO the string, and then called $__lang_strlen on that pointer to find out how much was left. The length of a Mere str lives in a header immediately before byte0 — so for an interior pointer that read takes the string's own bytes as a length. It is bounded by a NUL scan on the other backends, which is why only Wasm blew up on it, and why str_len (str_trim s) was the shape that showed it rather than print (str_trim s).

It takes the original length once now, uses it to bound the skip, and subtracts what the skip consumed. A NUL inside the value stays a byte through str_trim, on all four backends.

The Wasm host still writes up to the first NUL, and the reason turned out to be sharper than "something overstates its length": the self-hosted Wasm backend emits the pre-header string representation — its $__lang_strlen scans for a NUL and its strings carry no header — while stamping the same ABI number as the compiler that does. The host is shared between both kinds of module, so it cannot trust the header until the self-hosted backend carries one, or stops claiming the ABI that says it does. That is written down where the parity case pins it.

v0.1.261 — 2026-08-15

_print writes the string's length, and the two backends that cannot are pinned._

str became byte-safe in the v0.1.129 arc: the length lives in a header rather than in a terminator, and str_len (chr 0 ++ "X") has answered 2 ever since. print did not — it went out through puts, which stops at the first NUL — so the same value measured 2 and printed one character. Two answers about one value is a bug, not a choice, which is what the open question about this asked to settle.

The C backend writes by length now (print, print_err, print_no_nl), and matches the interpreter byte for byte.

The other two are pinned rather than fixed, each for its own reason, in a new parity case that prints NUL-carrying strings as well as measuring them:

• LLVM has no length header at all — its str is a bare pointer, and

str_len (chr 0) is 0 there against 1 everywhere else. The NUL is not truncated on output; it was never in the value.

• Wasm has the header and str_len reads it, but the JS host writes what it

finds up to the first NUL. Making the host trust the header instead surfaced a second thing: one str on the self-hosted compiler's path arrives with a header that overstates its content by half a megabyte of zeros. Until that is understood the host keeps scanning, and the pinned case is where it will be noticed.

Pinning is the point. Dropping U+0000 from the case — which is what happened the first time this came up — would have made the file agree by not asking.

v0.1.260 — 2026-08-15

_Exponent notation, because the ends of the double range could not be written down._

1.7976931348623157e308 lexed as the float 1.7976931348623157 applied to a variable named e308. A probe that needed the largest finite double, the smallest normal and the smallest subnormal had to build all three out of powers of two — scaling by halves until the value stopped changing — rather than write them.

Now a literal with an exponent is a float, with or without a decimal point: 1e3, 2.0e-3, 4E+5. A digit has to follow the e (after an optional sign), so 1.5 e is still a float applied to a variable called e, which is the only thing this could have taken away.

The formatter had to change with it. string_of_float keeps 12 significant digits, which was enough for every literal that could be written before and is not enough now: formatting 1.7976931348623157e308 would have written a different number back. It emits the shortest form that reads back as the same double.

And then the notation paid for itself immediately. A new parity case walks the float values four backends had never been asked about — the ends of the range, the subnormals below the smallest normal, both zeros, NaN — none of which could be reached before, because every float literal in the suite was one a human types. It found a real divergence on the first run: `nan < 0.0` was true on the interpreter and false on all three compiled backends. The interpreter routed every ordered comparison through OCaml's total compare, which sorts NaN below everything; the operator is IEEE, where every ordered comparison with NaN is false. Sorting still uses the total order — that part was deliberate — but < on two floats is now the float comparison, and the four backends agree.

v0.1.257 — 2026-08-14

_The tokenizer switches its own state after a start tag, which is a shortcut with a stated boundary rather than a guess._

used to tokenize as a start tag, a bare t, and an end tag, because the content of a title is RCDATA and the standard has the tree builder decide that. A tokenizer handed a whole document cannot ask.

For HTML the decision is a pure function of the tag name, so the tokenizer makes it: title and textarea go to RCDATA, style and its relatives to RAWTEXT, script to script data, plaintext to PLAINTEXT. The exception is foreign content —