language: the design of foreign functions #84
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
Foreign functions are a draft (CONCEPT);
std/gpuneeds them. The decision aboutforeignin published packages belongs to it.Source
Acceptance criteria
Dependencies
None known.
Moved from the planning lists of the docs; the design record stays the specification.
std/gpu#85[loop:torbscript] intake: in scope (author orion, label loop), source COMPUTE.md section 2, not a duplicate. A design-record issue on foreign functions; the technical design is decided by the loop in refine, but the record asks for the owner's sign-off and the decision about
foreignin published packages touches a published contract, so refine files that part as an owner decision. next: refine, waiting (ready buffer full: #4, #163, #164, #223 are ready) until 2026-10-10T04:00:00Zstd/gpu#85std/tensoron the CPU (step 1 of #82) #438std/tensoron the CPU #82[loop:torbscript] claim refine by session:loop-torbscript-20261024 until 2026-10-24T04:14:22Z
[loop:torbscript] decided by the loop: split. The technical design (types and ABI, how the C back end and the VM call, library resolution, ownership, callbacks, slices) is separable and goes to #459 (
docs/design/FOREIGN.md, docs only, one commit), which isready. Reasoning:foreignis parsed and shape-checked today, the capability "foreign functions" is already derived from source (compiler/src/package/archive.trb), the sandbox never grants it, andPointer/CStringexist nowhere instd/- so the record has to fix the mechanics beforestd/gpu(#85). Open technical questions are decided inside #459, not asked. Two inconsistencies are resolved there: CONCEPT wants aforeignnote inproject.trbwhile PROJECT.md section 1 says a manifest switch is a second source of truth (working assumption: capability from source,project.trbonly maps library names), and OS.md section 8 cites rule 7 of the sandbox page where it is rule 8.[loop:torbscript] owner decision: may a published package declare
foreignfunctions (a binding to a C library) and may it carry C sources? This is the published contract of the registry (RELEASE.md section 2 names it as a 1.0 decision; FIRST-PARTY.md row 7,torb/sqlite, cannot be built until it is answered), so the loop does not decide it. Options: (1) none: published packages stay pure TorbScript; (2) declarations only, against libraries already on the user's machine, no C sources in the package; (3) as (2), and first-party packages (torb/*) may also ship C sources that the toolchain compiles; (4) any package may ship C sources. Whatever is chosen,foreignstays visible in source, shown bytorb addand the lock, and never grantable to a sandboxed script. Recommendation: (2) - it unlocks bindings such as SQLite on Linux and macOS, keeps the registry a store of source that runs and builds nothing, and leaves (3) open as a later, separate decision; (1) blockstorb/sqlitefor good, (4) puts unreviewed C into every consumer's build. The answer is written into the open section of the record by a small follow-up PR, into RELEASE.md section 2 and into FIRST-PARTY.md. Blocking question below.[loop:torbscript] refine: split done. Technical part is ready as #459 (design record
docs/design/FOREIGN.md, docs only, one commit,ready). This issue keeps only the owner decision above (foreign functions in published packages: options 1-4, recommendation 2); the answer lands in #459's open section by a follow-up PR once given. Epic checklist: [ ] #459 design record (technical) - [ ] owner decision on published packages (comment above) - [ ] follow-up PR writes the answer into FOREIGN.md, RELEASE.md section 2 and FIRST-PARTY.md row 7 - [ ] implementation slices as listed by the record, filed just in time. Note for the tick: the tasks tooling has no access to git.torb.dev (question_askanswers "not found or no access"; orion/tasks#97 is closed), so nohos-questionblock exists for this decision yet; the plainowner decision:comment is the record, the tick needs to ping it to the TorbScript group in German (headline: "Dürfen Pakete C-Bibliotheken ansprechen?", recommendation: yes, but only bindings to libraries already on the machine, no C sources in the package). next: waiting (owner decision on foreign functions in published packages)[loop:torbscript] wait: the owner decision on foreign functions in published packages (options 1 to 4 above, recommendation 2) is asked in the TorbScript group and not answered yet; the technical record #459 is closed. Nothing else on this item can move.
next: waiting (owner decision on foreign functions in published packages)
std/gpu#85std/learning#86