Skip to content

ParseTable carrier: prepare grammar once above the assemble fold (validate-once) - #6569

Merged
briansrls merged 8 commits into
mainfrom
session/smart-eagle-362
Jul 14, 2026
Merged

briansrls merged 8 commits into
mainfrom
session/smart-eagle-362

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

ParseTable carrier — prepare the grammar once, not per module

Finding

grammar_validate_for_parse runs five whole-grammar checks (undefined-nonterminals, duplicate-productions, left-recursion, choice-ambiguity, nullable-ambiguity) plus the FIRST/nullable analysis — all pure functions of the invariant 841-row grammar — inside parse_module. So a door call over a K-module import closure re-validated the same grammar K times, and compute_grammar_first_analysis ran twice per module (once for the ambiguity check, once in parse_table_for_production).

The ParseTableRealization carrier already had grammar_digest / nullable_set / first_rows / materialization slots — but the cache lookup is Miss-stubbed (resolve_cache_miss), so nothing was reused. This was a recompute-per-module bug, not a missing cache.

Measured (release claim_batch, wet, std.determinism): one parse+normalize ≈ 14.7s, of which grammar_validate_for_parse alone ≈ 9.2s, re-paid every module.

Fix (correctness by construction)

A PreparedGrammar carrier + prepare_grammar (well-formed check + validate + analyze, once) hoisted above fold_list in program_assembly_fold_ingest; parse_module_prepared reuses it for every module. A door call now validates its closure once, not K times — structurally, no timing gate.

  • parse_module / parse_production / parse_table_for_production / program_assembly_read_to_normalized_root keep backward-compatible wrappers (prepare ∘ parse). Only the internal fold_step signature changed (no external callers).
  • Empty-ingest is guarded so zero modules never pay the one-time preparation.

Proven by execution

  • Behavioral equivalence — the ledger histogram witness stays green with identical causes (determinism→fact_density_hollow_alias_locus, error_primitives→resolve_reason_unbound_symbol, bit→resolve_ambiguous_export).
  • Amortization — parse_table_grammar_memo_multi_file_ingest_parses green; a 2-file fold costs ~9.2s = one preparation (not ~18.4s = two).
  • New empty-ingest guard witness green in 4ms (no prepare, no parse).

Follow-up (not this PR)

Cross-call content-addressed memo (sharing the prepared grammar across door calls) is gated on wiring the currently Miss-stubbed cache backend. Draft until by-execution sign — load-bearing parse stage.

🤖 Generated with Claude Code

Brian Searls and others added 8 commits July 14, 2026 00:09
…idate-once)

grammar_validate_for_parse (5 whole-grammar checks + FIRST/nullable analysis,
~9.2s, all pure fns of the invariant grammar) ran inside parse_module — so a
door call over a K-module import closure re-validated the SAME grammar K times,
and compute_grammar_first_analysis ran twice per module (ambiguity check +
parse_table_for_production). The cache-interface fields on ParseTableRealization
(grammar_digest/materialization) were inert; the backend lookup is Miss-stubbed,
so this was a recompute-per-module bug, not a missing cache.

Fix (correctness by construction): PreparedGrammar carrier + prepare_grammar
(well-formed + validate + analyze, once) hoisted ABOVE fold_list in
program_assembly_fold_ingest; parse_module_prepared reuses it per module.
parse_module / parse_production / parse_table_for_production / read_to_normalized_root
keep backward-compatible wrappers (prepare then parse). Empty-ingest guarded so
zero modules never pay the one-time prepare. Only fold_step's signature changed
(internal, no external callers).

Behavioral equivalence proven by execution: ledger histogram witness green with
IDENTICAL causes (determinism->fact_density, error_primitives->resolve_unbound,
bit->resolve_ambiguous_export); parse-table amortization green (2-file fold = one
preparation, ~9.2s not ~18.4s); new empty-ingest guard witness green (4ms, no prepare).

Cross-call content-addressed memo (across door calls) is the follow-up, gated on
wiring the currently Miss-stubbed cache backend.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@gunbai-bot
gunbai-bot Bot marked this pull request as ready for review July 14, 2026 03:19
@briansrls
briansrls merged commit f279274 into main Jul 14, 2026
6 checks passed
@briansrls
briansrls deleted the session/smart-eagle-362 branch July 14, 2026 03:47
briansrls added a commit that referenced this pull request Jul 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant