Activity

1. hyperpolymath commented on May 30, 2026

   

   hyperpolymath

   on May 30, 2026

   OwnerAuthor

   More actions

   Review: Proposal 0001 wire-format coverage from affinescript producer side

   Evidence-based answers to the four review questions, citing current affinescript codegen state (lib/codegen.ml, lib/wasm.ml, lib/tw_ownership_section.ml, lib/tw_verify.ml, lib/tw_interface.ml). Verdict per question + seam-risk flag + producer-asymmetry note.

   1. WasmType coverage (11-variant enum)

   Verdict: Covered (narrow) — 5 of 11 used, including WBool as i32.

   • lib/wasm.ml:11-16 defines value_type = I32 | I64 | F32 | F64 (no narrow ints, no v128, no reference types).
   • lib/codegen.ml:180-190 (type_to_wasm) maps every AffineScript type into those 4 wasm value types.
   • WBool is emitted as I32 (line 183: TyCon id when id.name = "Bool" -> Ok I32). No 1-byte packing.
   • No U8/U16/U32/U64/I8/I16 codegen paths; no SIMD; no externref/funcref.

   2. PtrKind coverage (4-variant enum)

   Verdict: Exact fit — all 4 kinds map 1:1 to AffineScript qualifiers.

   • lib/tw_ownership_section.ml:30-34 defines the 4-kind enum Unrestricted | Linear | SharedBorrow | ExclBorrow matching proposal's Scalar | PtrOwning | PtrBorrow | PtrExclusive (with the rename Scalar↔Unrestricted reconciled in tw_interface.ml).
   • AffineScript surface qualifiers (own, ref, mut) map to Linear, SharedBorrow, ExclBorrow respectively; scalar parameters use Unrestricted.
   • No &mut-equivalent or other modes outside this set exist in codegen today.

   3. Variable-length cardinality

   Verdict: Fixed-only — N/A for variable-length at v0.

   • Array layout is [length: I32][elem0][elem1]... (per lib/codegen.ml:1235), with statically-known cardinality at type definition time.
   • AffineScript has no dependent types; all records are fixed-shape.
   • The proposal's n>1 (fixed-array) case is reachable from affinescript if/when array fields land; 0 (unbounded/dynamic-bounds) and 1 (single value) cover today's emission.

   4. Capability indices ordering

   Verdict: Not emitted yet — typedwasm.capabilities section absent from codegen.

   • No capability table, no per-function required-capability emission path exists in lib/codegen.ml or lib/tw_ownership_section.ml.
   • tw_ownership_section.ml:77-96 iterates ownership annotations in source order without sorting. When capabilities land, a List.sort_uniq compare at build time will satisfy strictly-increasing trivially.

   Seam risk discovered while reviewing

   build_section is duplicated between producer and verifier copies:

   • lib/codegen.ml:159-177 defines the producer-side section assembly (called at codegen.ml:2778).
   • lib/tw_ownership_section.ml:77-96 defines an identical-encoding section assembly, used by the verifier-side reader (tw_interface.ml).

   Both currently encode the same fixed format, so this is not a correctness seam today, but:

   • It is a merge-risk seam if either changes unilaterally.
   • The proposal adds two more sections (typedwasm.regions, typedwasm.capabilities) — replicating this pattern would create a 3× duplication problem.

   Suggestion for landing the proposal: extract a single Tw_section.encode module that producer and verifier both consume. Worth filing as a separate prep-work issue before the proposal's codegen plumbing lands. I'll file it as a sibling.

   Cross-cutting observations (seam-analyst hat on)

   • v0 producer surface is narrower than the spec. Across affinescript (this review) and ephapax (docs: refresh #135 triage (r2) after slices 5-8 #165), no producer emits v128/SIMD, 128-bit ints, reference types, capabilities, or variable-cardinality fields at v0. The wasm_ty byte's 11 variants are forward-compat headroom — cheap to keep, worth flagging as "reserved at v0" so consumers don't preallocate handling for codepoints no producer will hit.
   • Producer asymmetry: affinescript exposes all 4 PtrKinds in codegen; ephapax (per docs: refresh #135 triage (r2) after slices 5-8 #165) exposes only 2 (Linear, Unrestricted). The verifier's contract for partial carriers (proposal lines 169–172: "Either emit all fields of all regions it accesses, or emit none") covers this gracefully — affinescript will emit dense, ephapax will emit sparse, both are spec-conforming.

   Bottom line

   Proposal 0001 is sound from affinescript's perspective. The wire format covers AffineScript's emission needs and forward-compat headroom is reasonable. The duplicate-build_section seam is a prep-work item, not a proposal defect.

   Greenlight from affinescript for proposal-0001 promotion to [accepted].

   ---

   Refs hyperpolymath/typed-wasm#34 hyperpolymath/typed-wasm#76 hyperpolymath/ephapax#165
2. hyperpolymath commented on May 30, 2026

   

   hyperpolymath

   on May 30, 2026

   OwnerAuthor

   More actions

   Review: Proposal 0001 (multi-producer carrier sections) + Proposal 0002 (access-site carrier)

   Reviewing for affinescript-the-producer (lib/tw_*.ml + lib/codegen.ml). I've covered both proposals together because proposal 0002 (typed-wasm PR #86, merged 2026-05-28) landed after this review-request was filed and answers proposal 0001's Open Question §5 — the two now have to be assessed jointly. Surveyed affinescript main at the file:line refs cited below.

   Headline verdict. The wire formats in both proposals are sound and emittable from affinescript in principle. Adopting them in practice will require producer-side IR work that affinescript has explicitly Roadmap-deferred (borrow.ml:1724-1730 defers Polonius-surface region inference to Roadmap C1; capability tracking is C2). Recommendation: promote 0001 + 0002 from [draft] → [review] (wire-format-validated for affinescript), with explicit acknowledgement that affinescript L2 enforcement on emitted wasm is gated on Roadmap C1 / C2 / a new C3 (access-site instrumentation).

   ---

   §1 — Section name rename (typed-wasm#65) status

   Rename to typedwasm.ownership is COMPLETE in all active source files. Every emitter and consumer in lib/, bin/, test/, tests/ uses "typedwasm.ownership". Surviving affinescript.ownership strings appear only in frozen historical records (.machine_readable/6a2/STATE.a2ml, META.a2ml, docs/history/, CHANGELOG.md) describing the section's name at a prior commit — i.e., historical record, not active code.

   Adjacent observation: affinescript.tea_layout (in lib/tea_bridge.ml, lib/tea_cs_bridge.ml, lib/tea_router.ml) is a separate, AffineScript-private custom section in the affinescript.* namespace that has not been renamed. This is correct — typed-wasm never claimed that name; it is genuinely AffineScript-specific. Worth a one-line note in proposal 0001 §"Producer obligations" that producers MAY emit private sections under their own namespace alongside the typedwasm.* set, to avoid future confusion.

   No seam mismatch. ✅

   ---

   §2 — Section codec readiness (the easy lane)

   The custom-section infrastructure is Wasm.wasm_module.custom_sections : (string * bytes) list (wasm.ml:260) — additive list entries, no structural constraint. Adding typedwasm.regions and typedwasm.capabilities builders+parsers is mechanical.

   Adjacent gap (worth surfacing to AffineScript maintainers): there is a duplicate build_ownership_section implementation. The extraction landed per Tranche A3 (2026-05-24) into lib/tw_ownership_section.ml:77-96, but lib/codegen.ml:151-177 still contains a verbatim copy AND codegen.ml:2778 calls the codegen.ml copy, not the extracted one. Both are alive; only one is reachable. This is a small but real source-of-truth seam — if proposal 0001 wire format ever evolves, both copies would have to be kept in sync until the codegen.ml copy is deleted. Recommend filing an affinescript follow-up to delete the codegen.ml duplicate and redirect line 2778 to call Tw_ownership_section.build_section. Not gating on this proposal but exactly the kind of latent inconsistency that bites multi-section maintainers later.

   Section codec verdict: ✅ no objection. Wire format is clean for affinescript to emit. Suggest fixing the duplicate-builder seam first as a defence against per-section maintenance drift.

   ---

   §3 — Answers to the four explicit questions in #402

   Q1 — WasmType enum mapping (11 variants)

   type_to_wasm (lib/codegen.ml:180-190) maps every source type to one of {I32, F64} only:

   • Bool, Int, Char, Nat, TyCon, TyApp, TyTuple, TyRecord, TyArrow → I32
   • Float → F64
   • catch-all → I32

   I64, F32 are present in Wasm.value_type (wasm.ml:13-16) and I64Const / F32Const instructions are partially generated, but type_to_wasm never produces them for source types. Narrow widths (U8/U16/I8/I16) are entirely unused — I32Load8U / I32Store8 etc. exist in Wasm.instr (wasm.ml:54-68) but codegen.ml generates zero uses of any narrow load/store.

   Critical for the proposal: Bool lowers to a 4-byte I32, not a 1-byte store. LitBool emits I32Const 0l / 1l (codegen.ml:373); subsequent I32Store writes a full 4-byte word. The proposal's WasmType enum has WBool = 10 as a discrete variant but does not specify whether WBool is 1-byte or 4-byte on the wire. AffineScript would emit it as 4-byte i32. Recommend the proposal pin this explicitly in §"Wire format":

   WBool: producer choice (i32.store / i32.store8 / i32.store16). Verifier validates that the load width matches the store width within a function and that the value never exceeds 0/1 by store-narrowing.

   Without this, AffineScript will emit one width and a future producer might emit a different width and the verifier has no canonical answer.

   Coverage conclusion: the 11-variant set covers AffineScript's current emission with massive room to spare — AS emits exactly 2 of 11. No reserved encoding slot needed for AS-specific types.

   Q2 — PtrKind distinction at emission

   Tracked at the function-parameter level only, not propagated to memory fields. The ownership_annots table in the context struct (lib/codegen.ml:22-67) carries ownership_kind per function parameter, populated at gen_decl TopFn dispatch (codegen.ml:2381-2397). The four kinds (Unrestricted, Linear, SharedBorrow, ExclBorrow) correspond to proposal's (Scalar, PtrOwning, PtrBorrow, PtrExclusive).

   However: the distinction is invisible at the memory-field layer. There is no ptr_kind_map in the context. All pointers lower to I32 heap addresses; the source-level TyOwn / TyRef / TyMut distinctions surface in the borrow checker and as ownership_kind annotations on function parameters, but are not attached to memory fields. The field_layouts / struct_layouts tables in codegen.ml track byte offsets and widths, not ptr-kind.

   Producer-side gap: emitting typedwasm.regions with per-field PtrKind annotations would require extending the layout tables with ptr-kind metadata that survives lowering. This is straightforward (add a column to field_layouts) but is not free — it's a deliberate codegen.ml change touching every struct emission site.

   Not a proposal-blocker. Filing a sub-issue against affinescript ("propagate PtrKind to field_layouts") would be a useful precondition for AS to start being an L2-conforming producer.

   Q3 — Variable-length region fields

   None today. Struct emission uses fixed 4-byte-per-field offsets (i * 4) throughout codegen.ml. All struct fields have static, fixed-width layouts. Cardinality=0 (unbounded) has no current equivalent in AffineScript emission and no infrastructure for it.

   The proposal's "downgrade to L5-runtime-check" default for unbounded fields is fine; AffineScript will never exercise that path in v1 — all emitted regions will have cardinality ≥ 1.

   Q4 — Strictly-increasing capability indices

   No capability tracking in AffineScript codegen or type checker. The capability type in lib/backends/architecture.ml:30 is a backend-capability enum (SIMD support, threads, etc. — selects backend features) and is unrelated to typed-wasm capability semantics. lib/borrow.ml:1725 places session-types + capability tracking under Roadmap item C2 ("not yet started").

   Emitting sorted, distinct u32le[] per function would be entirely new work. The format itself is fine — sort+dedup at emit-time is trivial — but the source of the data does not yet exist in AffineScript's pipeline.

   Producer-side gap, not a proposal-blocker. Filing a sub-issue against affinescript ("kick off Roadmap C2 — capability tracking → typedwasm.capabilities emission") would be useful pre-emptive scoping work.

   ---

   §4 — The Roadmap-deferred elephant

   This is the strategic finding the original #402 questions don't surface. Proposals 0001 + 0002 expect three families of IR data that AffineScript has explicitly Roadmap-deferred:

   1. Region inference. lib/borrow.ml:1724-1730 documents that origin/region variables (Polonius surface) are deferred under Roadmap C1, ADR-gated, and not yet in M1. The borrow checker today uses lexical lifetimes only. The context record in codegen.ml has no region_annots / region_map. There is no region IR at any pipeline stage. typedwasm.regions cannot be populated until C1 lands — and C1 is not currently scheduled.

   2. Capability tracking. Roadmap C2 — not started. (§3-Q4 above.)

   3. Access-site mapping (proposal 0002). No instruction-to-region mapping. I32Load instructions emit inline in gen_expr with computed offsets (codegen.ml:506, 566, 678, 920, 1028, 1033, 1566, 1600, 1640) and no annotation linking the load back to a region/field. Threading site metadata through the codegen pass is a separate, large change — let's call it Roadmap C3.

   The proposal correctly anticipates this in 0002's "Producer obligations" §1 ("AFTER any post-codegen wasm rewrite"), but the producer-obligations sections of both 0001 and 0002 understate the IR readiness required. Recommend adding a §"Producer readiness checklist" to both proposals — (a) stable region-id allocation, (b) field schema IR with PtrKind, (c) access-site instrumentation surviving post-codegen rewrite. AffineScript's existing Roadmap items C1 / C2 / (new) C3 map onto exactly this list and would let language teams scope their adoption explicitly.

   For affinescript specifically: the v1 verifier surface (carrier-section parsing + lenient-reader, behind unstable-l2 etc.) can be wired up immediately because that's verifier-side, not producer-side. Actually emitting populated typedwasm.regions from AffineScript is downstream of C1.

   ---

   §5 — Proposal 0002 — access-site carrier

   The wire format (LEB128 per field, ~5 B/access, ~1.1% module overhead) is the right choice for AffineScript — AS modules tend to be larger with denser typed access (more aggressive struct/record usage than ephapax), and encoding B's per-access overhead saves real bytes vs A's flat width.

   Three specific concerns for AffineScript:

   1. "AFTER any post-codegen wasm rewrite" producer obligation (0002 §"Producer obligations" ci: Bump actions/setup-node from 4.0.2 to 6.3.0 #1). AffineScript does not currently invoke wasm-opt or any post-codegen rewriter; the section can be emitted directly after Codegen.gen_module. However: any future wasm-opt-style pass added to the AS pipeline would have to be co-designed with access-site emission (re-emit the section after rewrite, or maintain an offset-mapping side-table through the rewrite). The proposal mentions AccessSiteMisalignment as the failure mode but does not specify a way for the producer to detect drift proactively. Recommend: a crates/typed-wasm-verify/ lint that flags access-site offsets falling in the middle of multi-byte opcodes (probable sign of a rewrite-without-re-emit), and a corresponding AS producer-side smoke test in tests/. Not gating; defensive.

   2. "NOT required to be sorted in v1" (0002 §"Wire format" notes). AS codegen emits in deterministic source order, which would happen to be sorted by (func_idx, instruction_byte_offset) by construction. Free ordering in v1 is fine; the "future v2 MAY require sorted" hedge means AS's natural emission is already v2-compatible — recommend documenting this explicitly in 0002 so future producers don't accidentally regress by reordering.

   3. Producer obligation ci: Bump dtolnay/rust-toolchain from f7ccc83f9ed1e5b9c81d8a67d7ad1a747e22a561 to efa25f7f19611383d5b0ccf2d1c8914531636bf9 #2 ("Emit a typedwasm.regions section in the same module"). For AS, this means C1 must land before C3 makes sense — emit-order in the rollout. This is internally consistent for AS; just flagging that the proposal's strict dependency could be a sequencing constraint other producers might want to challenge. Suggest "or the verifier accepts access-sites without regions in a lenient mode" as an alternative path for incremental rollout — but accepting your "MissingDependentCarrier hard-error" stance for v1 is fine if access-sites isn't valuable without regions anyway.

   ---

   §6 — Cross-references already covered

   • Versioning policy (u16le version fixed-width, lenient additive, breaking-bumps-version): correct for AS. The tw_ownership_section.ml codec extends to version: u16 trivially.
   • Independent optionality: correct; matches AS's stance for typedwasm.tea_layout (private AS section is optional + parallel to typedwasm.* set).
   • L13 cross-module Open Question §5 in 0001 (region-id stability across module boundaries): not yet relevant for AS single-module emission but flag for when AS multi-module + cross-language imports happens — AS's module-import strategy will need to interact with this. Suggest filing typed-wasm sub-proposal 0003 (typedwasm.region-imports) proactively rather than discovering it later when AS+ephapax cross-import lands.
   • ADR-020 (v2 0xAF sentinel + version byte) for typedwasm.ownership: AS verifier-side parse support is shipped; emit-flip deferred per Q-001 ledger. Stays unaffected by proposals 0001 / 0002.

   ---

   §7 — Open questions back to typed-wasm

   1. WBool width. 1-byte or 4-byte on the wire? (§3-Q1 above.) AS emits 4-byte; ephapax would too (cross-validated in docs: refresh #135 triage (r2) after slices 5-8 #165). Proposal must pin a canonical answer or specify per-function-store-width validation.
   2. Producer-readiness contract. §4 above — recommend a §Producer-readiness checklist appended to 0001 (and 0002 referencing it).
   3. typedwasm.capability-grants (L15-C deferred). Is there a tracking issue yet? If not, suggest filing now so AS can scope C2 + a future C2.5 (per-call-site grants) together.
   4. Multi-section emit ordering. When AS emits typedwasm.ownership + typedwasm.regions + typedwasm.access-sites + typedwasm.capabilities, is the emit-order specified or free? Suggest fixed order (ownership, regions, capabilities, access-sites) matching their dependency graph, for consumer predictability — but a "any order" stance is also fine if documented.

   ---

   Recommendation

   [draft] → [review] for both proposals, conditional on §7 open questions being addressed (or explicitly deferred with tracking issues filed).

   AffineScript has no objection to the wire formats. The producer-side IR work to actually populate typedwasm.regions from AffineScript is gated on Roadmap C1; capability tracking on C2; access-site instrumentation on a (new) C3. Recording these explicitly in the proposals' producer-obligations sections would be honest expectation-setting and let AS plan its adoption schedule.

   Filing this comment satisfies AffineScript's gating role per 0001 §"Coordination with downstream producers."

   ---

   Refs: typed-wasm#34, typed-wasm#76 (proposal 0001 PR, merged), typed-wasm#78 (access-site carrier RFC, resolved), typed-wasm#86 (proposal 0002 PR, merged), typed-wasm#50 (Phase 2 tracking), affinescript Roadmap C1 / C2.

   Producer-side citations (all on affinescript main HEAD, 2026-05-30):

   • lib/codegen.ml:22-67, 151-177, 180-190, 373, 506, 566, 678, 920, 1028, 1033, 1566, 1600, 1640, 2381-2397, 2778
   • lib/tw_verify.ml:90-105, 124-154, 169-181, 218-303, 314-337, 343-359
   • lib/tw_interface.ml:75-80
   • lib/tw_ownership_section.ml:44-48, 77-96
   • lib/borrow.ml:1724-1730
   • lib/backends/architecture.ml:30
   • wasm.ml:13-16, 54-68, 260

   🤖 Reviewer context: typed-wasm + affinescript cross-repo review for proposal-0001 + 0002, filed 2026-05-30 by Claude Opus 4.7 on behalf of @hyperpolymath per #402's gating request.
3. hyperpolymath commented on May 30, 2026

   

   hyperpolymath

   on May 30, 2026

   OwnerAuthor

   More actions

   2026-05-30 — PR #104 filed: proposals 0001 + 0002 status [draft] → [review]

   Promoting both proposals (0001 via this issue's gating role; 0002 via #449's) from [draft] → [review] in typed-wasm#104. Both producer reviews on file in this issue recommended [review] (not directly [accepted]), pending remaining acceptance criteria (codec landing + spec doc + cross-repo codegen).

   Once PR #104 lands, this issue's gating role is fulfilled. Leaving open as the producer-side tracker until full [accepted] lands (per 0001 §Acceptance criteria 3+4+5).

   Adjacent CI fix typed-wasm#105 clears two pre-existing red checks (Cargo.lock dup + nextgen-languages allowlist) blocking auto-merge.

   🤖 Status update from review-promotion closeout.
4. hyperpolymath

   added 2 commits that reference this issue on May 30, 2026

   docs(proposals): promote 0001 + 0002 status [draft] → [review] (#104)

   ...

   3c90f37

   docs(proposals/0001): annotate v0 producer surface — flag reserved co…

   ...

   4ac7a5a
5. hyperpolymath commented on May 30, 2026

   

   hyperpolymath

   on May 30, 2026

   OwnerAuthor

   More actions

   Closing — both proposals are now [accepted]:

   • Proposal 0001 ([accepted] in typed-wasm#115) — multi-producer carrier sections for L2–L6 and L15.
   • Proposal 0002 ([accepted] in typed-wasm#115; also tracked at Cross-repo review request: typed-wasm proposal 0002 (typedwasm.access-sites carrier) #449) — typedwasm.access-sites carrier.

   Both promoted to ADRs (ADR-0002 + ADR-0003). AffineScript-side codegen follow-up is tracked at #462.
6. hyperpolymath

   closed this as completedon May 30, 2026