natives: native fn bodies as IR and native { } blocks #53
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
The body of a
native fnbecomes IR andnative { ... }a block of IR inside an ordinary function (CONCEPT, "Foreign Functions"), sostd/says which operationInt64.addis.Source
Acceptance criteria
docs/design/NATIVE-BODIES.md(#410, PR #412)mainstduses it for its arithmetic (second commit of the two-commit rule, filed when the seed is refreshed): 4aInt64, 4b integer widths andBits, 4c floats, conversions and the kind-less rowsDependencies
Notes
Adds or changes a native, syntax or a name the compiler looks up: land it in two commits (teach both forms, refresh the seed, then migrate), as
CLAUDE.md"Seed and breaking changes" says.Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop), source ROADMAP.md kernel of natives and CONCEPT "Foreign Functions", not a duplicate. New syntax, so seed-relevant (two-commit rule); depends on #52. next: waiting (dependency #52 and ready buffer full) until 2026-10-10T04:00:00Z
[loop:torbscript] claim refine by session:loop-torbscript-20261023 until 2026-10-23T05:19:26Z
native fnandnative { }(step 1 of #53) #410[loop:torbscript] decided by the loop: #53 is an epic and is split just in time. No design record specifies the surface of IR bodies (CONCEPT only plans it; BACKEND has the IR text and the
Intrinsicset,natives.trbholds the manifest it replaces), so the record is the first step: #410, documentation only, no seed impact. Why first: syntax, checker rules and lowering in two back ends are too large for one PR and each later slice depends on the grammar; the two-commit rule (new syntax) applies to the implementation slices, not to the record. The syntax choices follow CONCEPT and the IR text of BACKEND and are made by the record itself (language-surface choice following existing design, no design record reserves it for the owner); the seed refresh stays Torben's. The remaining slices (parser, checker, lowering in VM and C,stdarithmetic migrates) are filed one at a time when each starts, after the audit table of #52 (#407) fixes which rows become bodies.[loop:torbscript] refine: epic; first step filed as #410 and marked
ready(not this issue). Remaining steps, filed when each starts: parser and syntax gate test, checker rules, lowering in VM and C back end,stdmigrates its arithmetic (each new-syntax slice under the two-commit rule). Tokens used by this refine run: about 90k.next: waiting (epic waits on its steps)
ArrayList, the hash tables and the tries onBuffer(step 1 of #55) #413[loop:torbscript] claim refine by session:loop-torbscript-20261024 until 2026-10-24T09:10:00Z
native fnbodies andnative { }blocks, with a parser gate test (step 2 of #53) #467native fnbodies andnative { }blocks, with a parser gate test (step 2 of #53) #467[loop:torbscript] refine: step 2 filed as #467 and marked ready, next: waiting (epic waits on its steps, #467 next). Tokens used: about 30k
[loop:torbscript] claim refine by session:loop-torbscript-20261025-0258 until 2026-10-25T03:15:00Z
[loop:torbscript] refine: step 3 (checker rules N1-N10 plus the shared intrinsic typing table) filed as #478 and marked ready; step 2 (#467, PR #472) is landed and closed, so the earlier note "#467 next" is stale. Remaining steps, filed when each starts: lowering in VM and C back end (then the seed refresh, Torben's),
stdmigrates its arithmetic (4a Int64, 4b widths and Bits, 4c floats, conversions, kind-less rows; second commit of the two-commit rule). Tokens used by this refine run: about 60k.next: waiting (epic waits on its steps, #478 next)
[loop:torbscript] claim refine by session:loop-torbscript-20261025-1622 until 2026-10-25T17:45:00Z
native fnbodies andnative { }blocks, kernel test (step 4 of #53) #484[loop:torbscript] refine: verified against main: #410 (record), #467 (parser, PR #472) and #478 (checker N1-N10 and the typing table, PR #480) are landed and closed; lowering is not (main still answers a well-formed body with "its native body is not lowered yet"), so the earlier note "#478 next" is stale. Step 4 filed as #484 (lowering in the shared Intrinsic path for C and VM, missing-intrinsic finding, kernel test; two commits; seed-relevant but builds on the current seed) and marked
ready; the epic checklist now lists the landed steps, #484, the seed refresh and thestdmigration (4a Int64, 4b widths and Bits, 4c floats, conversions, kind-less rows). Thestdmigration is not filed yet: it needs the seed refresh after #484, which is Torben's step and forbidden to the loop. Tokens used by this refine run: about 90k.next: waiting (epic waits on #484; after it lands, on the seed refresh by Torben before the
stdmigration is filed)[loop:orion] note refresh (infra#2006): #484 is closed (2026-10-26T10:35Z), so the wait note named only a closed issue and raised a stale-wait finding. The remaining condition is not an issue: the seed refresh is Torben's step (checklist item 5), and no seed refresh is on main yet. The
stdmigration is filed after it.next: waiting (seed refresh by Torben, then the
stdmigration is filed)[loop:torbscript] refine: re-checked main at 2026-10-29T17:05Z: #410, #467, #478 and #484 are landed; no seed refresh is on main yet (checklist item 5 is Torben's step), so the
stdmigration (4a to 4c) is not filed. Nothing for the loop to do on this epic.next: waiting (seed refresh by Torben, then the
stdmigration is filed)