ir.data.generated has drifted structurally from the active IR data layer — retire or rehabilitate

[mparrett]

While working on #558 I looked closely at the spec-generated data layer, and the problem is bigger than a missing field. Summary of what I verified on current main:

• Structurally incompatible, not just stale. The active hand-written layer (pkg/rt/core/ir/data.lg) stores insts as positional vectors, with source infos in a side table since perf(ir): source-infos in a positional side table, off the inst tuple #306 (and inferred types joining them in perf(ir): move inferred types to a positional side table — ~100x faster type writes #558). The generated layer (pkg/rt/core/ir/data/generated.lg, from the pkg/ir/ir_data.lg spec) still emits keyword-map accessors — (:type (nth (:insts @f) nid)), swap! + assoc-in setters — against an inst shape the IR no longer uses. Reading a real Function through it returns wrong answers (e.g. type-of gives nil where the active layer gives the inferred type).
• No consumers. No .lg or Go file requires ir.data.generated outside the generator and its own artifacts.
• Still generated, compiled, and shipped. scripts/generate.lg regenerates it; it lowers to a 35-function, ~35KB Go package (core_go_lowered/ir/data/generated) that the gogen_ir build links via cmd/lgbgen/main_gogen_ir.go.
• The README points contributors at it. pkg/rt/core/ir/README.md lists data/generated.lg as the home of mechanical field accessors and instructs running make generate-ir-data — a target that doesn't exist in the Makefile.

So the repository maintains, generates, ships, and documents a second IR data API that disagrees with the authoritative one, and the drift compounds every time the active layer moves (#306 didn't update it,
#558 couldn't meaningfully either — adding :types to a spec that
still models keyword-map insts wouldn't reconcile anything).

Two ways out:

1. Retire it (my recommendation): drop the gen-lisp line from scripts/generate.lg, delete data/generated.lg and its lowered package, remove the blank import, and rewrite the README section around the hand-written layer. Given zero consumers and two side-table migrations that didn't touch it, this is the smaller and safer change.
2. Rehabilitate it: teach ir_data.lg the positional tuple + side-table representation and add an equivalence test that pins generated accessors to the hand-written ones, so the next representation change fails loudly instead of drifting silently.

Happy to send the retirement PR if that's the direction you want. If the spec-driven approach still figures in your plans, option 2 without the equivalence test would just re-arm the drift.

🤖 Generated with Claude Code