INTERCEPTS conflates two concepts: compiler-supplied bodies vs optimisation of a real body #41

New Issue

2026-05-29T17:51:57+02:00

Brummel commented

2026-05-29 17:51:57 +02:00

Surfaced during the intrinsic-bodies milestone (audit of caa3618).

The codegen intercept registry crates/ailang-codegen/src/intercepts.rs::INTERCEPTS mixes two semantically distinct kinds of entry:

Intrinsic-backed (14 entries): the fn has no real body — the source carries (intrinsic) (Term::Intrinsic) and the compiler supplies the implementation. The 7 prelude Eq/Ord instance methods, the 6 float_* fns, and the answer ratifier. Closing the honesty-rule infraction on these is exactly what intrinsic-bodies did.
Optimisation-only (5 entries): lt__Int, le__Int, gt__Int, ge__Int, ne__Int. These intercept the monomorphised __Int specialisation of the polymorphic free fns lt/le/gt/ge/ne, which carry real, honest bodies in the prelude (ne = (app not (app eq x y)); the four ordering helpers are (match (app compare x y) ...)). Those bodies are lowered for every non-Int instantiation; only the Int specialisation is intercepted for a faster direct icmp. No lie, no (intrinsic) marker.

The two are structurally indistinguishable in the registry today — both are just Intercept rows. The intrinsic-bodies.2 bijection pin (intercepts_bijection_with_intrinsic_markers) papers over the difference with a hardcoded 5-name OPTIMISATION_ONLY allowlist (a comment-level distinction, not a type-level one).

Possible direction (not committed): give Intercept an explicit kind field (e.g. IntrinsicBacked vs Optimisation) so the registry is self-describing and the bijection pin derives the allowlist from the data instead of a hand-maintained name list. A stale allowlist (a name added to one class but the pin not updated) would then be impossible by construction — the same make-illegal-states-unrepresentable discipline intrinsic-bodies applied to bodies.

Why deferred, not done now: out of scope for intrinsic-bodies (which is about the body surface, not the registry's internal taxonomy). Splitting the registry is its own focused change. The allowlist + the stale-allowlist guard in the pin contain the risk in the meantime.

No urgency: the bijection pin is green and guards both directions. This is a clarity/robustness improvement, not a correctness bug.

Verification 2026-06-02: Core concern still holds. Intercept (crates/ailang-codegen/src/intercepts.rs) still has no kind/enum field, and the bijection pin intercepts_bijection_with_intrinsic_markers still papers over the distinction with the hardcoded 5-name OPTIMISATION_ONLY allowlist (lt/le/gt/ge/ne __Int). Count drift: the registry has grown well past the original 14 intrinsic-backed entries (RawBuf intercepts landed since), so the taxonomy now spans intrinsic-backed + optimisation-only + RawBuf-runtime entries — which strengthens, not weakens, the make-the-kind-explicit case. Still an idea, no urgency; the pin is green.

Surfaced during the intrinsic-bodies milestone (audit of caa3618). The codegen intercept registry `crates/ailang-codegen/src/intercepts.rs::INTERCEPTS` mixes two semantically distinct kinds of entry: 1. **Intrinsic-backed** (14 entries): the fn has *no* real body — the source carries `(intrinsic)` (`Term::Intrinsic`) and the compiler supplies the implementation. The 7 prelude Eq/Ord instance methods, the 6 `float_*` fns, and the `answer` ratifier. Closing the honesty-rule infraction on these is exactly what intrinsic-bodies did. 2. **Optimisation-only** (5 entries): `lt__Int`, `le__Int`, `gt__Int`, `ge__Int`, `ne__Int`. These intercept the *monomorphised* `__Int` specialisation of the polymorphic free fns `lt/le/gt/ge/ne`, which carry **real, honest bodies** in the prelude (`ne = (app not (app eq x y))`; the four ordering helpers are `(match (app compare x y) ...)`). Those bodies are lowered for every non-`Int` instantiation; only the `Int` specialisation is intercepted for a faster direct `icmp`. No lie, no `(intrinsic)` marker. The two are structurally indistinguishable in the registry today — both are just `Intercept` rows. The `intrinsic-bodies.2` bijection pin (`intercepts_bijection_with_intrinsic_markers`) papers over the difference with a hardcoded 5-name `OPTIMISATION_ONLY` allowlist (a comment-level distinction, not a type-level one). **Possible direction** (not committed): give `Intercept` an explicit kind field (e.g. `IntrinsicBacked` vs `Optimisation`) so the registry is self-describing and the bijection pin derives the allowlist from the data instead of a hand-maintained name list. A stale allowlist (a name added to one class but the pin not updated) would then be impossible by construction — the same make-illegal-states-unrepresentable discipline intrinsic-bodies applied to bodies. **Why deferred, not done now:** out of scope for intrinsic-bodies (which is about the *body* surface, not the registry's internal taxonomy). Splitting the registry is its own focused change. The allowlist + the stale-allowlist guard in the pin contain the risk in the meantime. No urgency: the bijection pin is green and guards both directions. This is a clarity/robustness improvement, not a correctness bug. --- **Verification 2026-06-02:** Core concern still holds. `Intercept` (`crates/ailang-codegen/src/intercepts.rs`) still has no `kind`/enum field, and the bijection pin `intercepts_bijection_with_intrinsic_markers` still papers over the distinction with the hardcoded 5-name `OPTIMISATION_ONLY` allowlist (`lt/le/gt/ge/ne __Int`). Count drift: the registry has grown well past the original 14 intrinsic-backed entries (RawBuf intercepts landed since), so the taxonomy now spans intrinsic-backed + optimisation-only + RawBuf-runtime entries — which strengthens, not weakens, the make-the-kind-explicit case. Still an idea, no urgency; the pin is green.

Brummel added the idea label 2026-05-29 17:55:43 +02:00

Brummel referenced this issue from a commit

2026-05-30 12:53:00 +02:00

audit + close: intrinsic-bodies — honest prelude docs + lockstep table + stale-model fix (refs #9)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/AILang#41