Interoperability is a sequence of gated boundaries, not a percentage.
One verified artifact at a time.
The long-term objective is bidirectional ecosystem interoperability and broad target support. The current repository contains narrower compiler, host, loader, ABI, and generated-package slices whose source, execution, publication, and support states must be read separately.
entity Semaprax
status pre-alpha research
snapshot c16348f
authority github.com/wavect/semapraxRepository status at the audited snapshot
| Repository snapshot | c16348f · 2026-08-29. Documentation passed, but the overall workflow failed, so this head is not labelled verified. |
|---|---|
| Full product status | 49 Partial · 0 Implemented · 0 Missing |
| Graph and project contract | Graph ≤ v24 · Project v1 baseline · Project v8, v9, v10 developer preview |
| Promotion baseline | No exact passing promotion commit or workflow run is asserted for this snapshot. |
| Authored developer preview | Owned-data, record, and UTF-8 project profiles, package analysis, borrowing additions, Project Agent Transport, and Revision Store are present in source but unpublished or unpromoted. |
Which platforms and ecosystems does Semaprax support?
Semaprax retains bounded interpreter, C11/Clang, Core Wasm/Node, and scalar JavaScript/TypeScript lanes. Project v8 adds authored npm/Core-Wasm and safe Rust routes for Bytes, Option<Bytes>, and Result<Bytes, i64>; Project v9 and v10 add flat owned records and owned UTF-8. Those package surfaces are unpublished and unpromoted, and do not establish a stable general ABI or broad host-language compatibility.
Target support evidence
| Platform | Source state | Exact-head evidence | Publication state | Supported scope |
|---|---|---|---|---|
| Linux native | Partial | Earlier C11/Clang, Ubuntu host, loader, and sanitizer gates passed for admitted slices; c16348f overall CI failed Evidence | Bounded research artifacts | Bounded language and ABI slices, not general Linux application compatibility |
| macOS native | Partial | Earlier hosted macOS and desktop harness evidence; no exact-head green claim for c16348f Evidence | Private bounded harnesses | Host and package evidence does not prove a general macOS application platform |
| Windows native | Partial | Earlier hosted Windows, hardened loader, and desktop harness evidence; no exact-head green claim for c16348f Evidence | Private bounded harnesses | Bounded loader and package contracts, not general Windows application support |
| Browser and Wasm | Developer preview | Earlier scalar Core Wasm/Node evidence plus authored Project v8-v10 npm/Core-Wasm package routes at c16348f Evidence | Scalar baseline bounded; Project v8-v10 unpublished and unpromoted | Project v8 admits Bytes, Option<Bytes>, and Result<Bytes, i64>; v9 flat owned records and v10 UTF-8 remain unpromoted. No multi-browser or general Web API support |
| iOS | Partial | Bounded Swift ownership, static-surface, and arm64 simulator harness evidence; no complete exact-head product gate Evidence | Private bounded contracts | Private bounded contracts, not general App Store or iOS lifecycle support |
| Android | Partial | Bounded JNI ownership and Android emulator harness evidence; no complete exact-head product gate Evidence | Private bounded contracts | Bounded host contracts, not general Android application support |
Ecosystem boundary evidence
| Ecosystem boundary | Source state | Exact-head evidence | Publication state | Supported scope |
|---|---|---|---|---|
| C11 and Clang | Partial | Earlier deterministic C11 compilation and execution evidence at O0 and O2 for admitted slices; c16348f overall CI failed Evidence | Generated research backend | Generated backend boundary, not arbitrary C header or library interoperability |
| Rust native host | Developer preview | Earlier private scalar bridge evidence plus an authored safe Rust package route for Project v8 Evidence | Unpublished developer preview | The Project v8 route is unpublished and unpromoted. It admits only Bytes, Option<Bytes>, and Result<Bytes, i64>, not general Rust interoperability |
| WebAssembly and WIT components | Partial | Core Wasm/Node lanes and isolated component-runtime and WIT boundary fixtures; complete exact-head promotion remains open Evidence | Core Wasm bounded; general components unpublished | General public component mapping and broad package integration remain closed |
| Swift and JNI | Partial | Bounded Apple Swift and Android JNI ownership contracts; no full product gate Evidence | Private bounded contracts | No general bidirectional foreign-function interface or ecosystem package compatibility |
| Existing language ecosystems | Roadmap | Package reports, offline locks, and Compatibility Evidence v1 provide bounded analysis, not general compatibility Evidence | No stable general public ABI | General bidirectional FFI, stable public aggregate and resource ABIs, package compatibility, and full Component Model publication remain open |
Long-term objective
A program should cross native, browser, mobile, desktop, and existing-language boundaries without losing ownership, error, or semantic identity facts. That objective remains roadmap work until each public boundary has reproducible conformance evidence.
GitHub specifications are the normative source. This page is a dated research summary. GitHub repository.
Questions, answered without the hype
Does Semaprax support every native target?
No. It has bounded evidence across native, Wasm, desktop, iOS, and Android lanes. General platform support remains experimental or roadmap work.
Is Semaprax 100 percent interoperable with other languages?
No. Full bidirectional ecosystem interoperability is a long-term objective. Current evidence covers narrower generated C11, Rust-host, WIT, Swift, and JNI boundaries.