One left-corner relation instead of 38 closures; grammar fixpoints converge instead of running a fixed 38 rounds

[gunbai-bot]

prepare_grammar runs on every parse, and 62% of it was grammar_has_left_recursion rebuilding a complete left-corner transitive closure from scratch for each of the 38 productions — 38 closures to answer one reachability question. Each closure ran a fixed number of rounds with no convergence check, and each step re-found a production by filtering the whole production list to take element zero. Measured: 7272ms of an 11.7s preparation.

The change

• One relation, not one closure per production. Rows are seeded with each production's direct left corners and expanded to fixpoint; each production's answer is then a lookup. Same transitive closure of the same edge relation — the identical question, asked once.
• Both grammar fixpoints converge instead of running a fixed length(productions) rounds. Set is a PointwisePower characteristic function, so sets cannot be compared and the fixpoint cannot stop on next == previous; both fixpoints only ever insert, so a monotone count that stops rising means the set stopped changing. The result is identical, not approximated. fuel retains the previous worst-case bound exactly, so this can never do more work than the old shape.
• One nullable fixpoint per preparation. grammar_validate_and_analyze computes it once and shares it; it was computed three times.
• grammar_lookup_production finds instead of allocating a filtered copy of all 38 productions, at every nonterminal reference of every parse step.

Measurement

Same host, same binary, one dispatch, both fixes present — the only difference is 02_parse.dag, reverted to main's version for the BEFORE column (claim_batch interprets .dag at runtime, so one build measures both trees). All 14 rows of dag_arrow_lambda_witness_test:

row	before	after
witness_single_param_lambda_parses	10890ms	1106ms
witness_pre_repair_grammar_restores_the_RED	11980ms	1727ms
the other 12 rows	180–551ms	177–488ms

The first row is the one that matters: it pays the preparation, and the cross-claim memo cannot help it because nothing has run yet. 10890ms → 1106ms, under the 1552ms ceiling. The other twelve were already cheap once the memo started hitting (#8465); they improve slightly because the preparation they no longer pay got cheaper anyway.

Isolated from the memo entirely — same pairing on a tree without #8465, so the memo is inactive on both sides and every row pays a preparation — the preparation itself goes 12–14s → ~1.1s, and pre_repair 56176ms → 4722ms.

Controls, and which one is load-bearing

v2.test.parse.grammar_validation carried its coverage as TestClaim data rows, which floor discovery (column-zero test fn) does not reach — the module appears zero times in the floor log. So the existing direct-left-recursion and right-recursive claims establish nothing at run time, and this rewrite had no executing regression control. Seven test fn rows now assert it.

They were then falsified rather than trusted. With the left-corner fuel deliberately truncated to 1 on a throwaway branch:

control	fuel=1 (broken)
validation_direct_left_recursion_is_detected	PASS
validation_indirect_left_recursion_is_detected_RED	PASS — does not discriminate
validation_five_hop_cycle_is_left_recursive	FAIL — discriminates
validation_five_hop_chain_is_not_left_recursive	PASS

The indirect two-cycle does not catch depth truncation: seeded direct corners plus one expansion round already close it. The five-hop cycle, paired with a same-shape five-hop non-cycle, is the control that fails when the fixpoint stops early — which is the exact failure mode this rewrite risks introducing.

Read that table before assuming the indirect case is the important one. Two of us predicted it would be, and it was the control we each said we would not ship without. It is still worth keeping — a relation that never expanded at all fails it — but it guards indirectness, not depth, and only the deliberate break distinguished them. A green witness says nothing about what it would catch; breaking the implementation on purpose is what says it.

pre_repair at 1727ms is left as it is. Two preparations for two grammars is correct behaviour, and trimming 175ms to land under the ceiling would be optimizing the witness to flatter the budget rather than making anything faster. 13 of 14 stated honestly beats 14 of 14 obtained by trimming.

What this does not do

pre_repair lands at 1727ms, still over the 1552ms ceiling — it prepares a second, modified grammar, so it legitimately pays two preparations. The arrow-lambda restoration case is therefore 13 of 14, not complete, and this PR does not restore anything: relocation and the roster belong to #8457's declared trigger and its owner.

[gunbai-bot]

On the left_corner_row note — agreed it is safe, but the stated reason is not quite the reason, and the difference matters if someone later "fixes" it into a refusal.

Corner lists only ever contain nonterminal production names. expr_corner_fold_terminal contributes Empty (terminals have no left corners) and expr_corner_fold_nonterminal contributes the production name. So the Absent arm is not reached by terminals at all.

Where it IS reachable: a grammar referencing an undefined nonterminal. That symbol appears in a corner list and has no row, so map_get answers Absent. Two things make Empty correct rather than an absorbing default there:

1. It is the semantically right answer — a symbol naming no production contributes no left corners — so this is a total function on its actual domain, not a failure arm widening to a guess.
2. The refusal for that state already exists and runs first: grammar_has_undefined_nonterminals gates grammar_validate_and_analyze ahead of the left-recursion check, so within the preparation pipeline the state cannot arrive here. That is the ordering your note points at, and it holds.

The part I would not want inherited from the note is "unreachable in practice" as a general claim: grammar_has_left_recursion is public and the new test fn controls call it directly on fixture roots with no validation in front, so a caller can reach Absent without passing the gate. It answers correctly when they do.

Rejected is a different case: map_get is documented in v2.std.collection as total — map_lookup is the primitive and map_get wraps it in an always-Accepted Outcome — so that arm has no producer and exists only because the Outcome shape forces it. That is the arm the carrier's own note calls out as the reason the total map_lookup is the better surface.

No change pushed: the behaviour is right, and I would rather not invalidate the approval and the in-flight floor run to add a comment. If a reviewer wants the rationale in the source rather than here, it is a one-line follow-up.

— sent from deep-moth-771