Interoperabilität ist eine Folge verifizierter Grenzen, keine Prozentzahl.
Ein verifiziertes Artefakt nach dem anderen.
Langfristiges Ziel sind bidirektionale Ökosystem-Interoperabilität und breite Zielunterstützung. Das Repository belegt heute engere Compiler-, Host-, Loader-, ABI- und Paketpfade.
entity Semaprax
status Pre-Alpha-Forschung
verified 2026-08-11
authority github.com/wavect/semapraxWelche Plattformen und Ökosysteme unterstützt Semaprax?
Das v0.2-Repository demonstriert begrenzte native C11/Clang- und Browser/Wasm-Ausgabe sowie plattformspezifische Host- und Paket-Harnesses für Desktop, iOS und Android. Das ist noch kein allgemeiner Anwendungssupport und keine vollständige Interoperabilität.
Evidenz für Zielplattformen
| Plattform | Evidenzstatus | Verifiziertes Artefakt | Grenze | Roadmap-Phase |
|---|---|---|---|---|
| Linux nativ | Demonstriert | C11/Clang-Programme und gehostete Ubuntu-Compiler-, Host-, Loader- und Sanitizer-Gates Evidenz | Begrenzte Sprach- und ABI-Teilmengen | begrenzte Artefaktpfade |
| macOS nativ | Experimentell | Gehostete macOS-Matrix und Desktop-Paket-Harnesses Evidenz | Kein allgemeiner macOS-Anwendungssupport | Ownership- und Plattformverträge |
| Windows nativ | Experimentell | Windows-Matrix, Loader-Prüfungen und Desktop-Paket-Harnesses Evidenz | Begrenzte Loader- und Paketverträge | Ownership- und Plattformverträge |
| Browser und Wasm | Demonstriert | Browser-Pakete und reale Node/Wasm-Verifikation Evidenz | Keine vollständige Web-API- oder UI-Abdeckung | begrenzte Artefaktpfade |
| iOS | Experimentell | Swift-Ownership-, Static-Surface- und arm64-Simulator-Harnesses Evidenz | Private begrenzte Verträge, kein allgemeiner App-Support | Ownership- und Plattformverträge |
| Android | Experimentell | JNI-Ownership- und Emulator-Harnesses Evidenz | Begrenzte Hostverträge, kein allgemeiner App-Support | Ownership- und Plattformverträge |
Evidenz für Ökosystemgrenzen
| Ökosystemgrenze | Evidenzstatus | Verifiziertes Artefakt | Grenze | Roadmap-Phase |
|---|---|---|---|---|
| C11 und Clang | Demonstriert | Deterministisches C11, für zugelassene Teilmengen bei O0 und O2 kompiliert und ausgeführt Evidenz | Keine beliebige C-Header- oder Bibliotheksinteroperabilität | begrenzte Artefaktpfade |
| Rust Native Host | Experimentell | Host- und Loader-Crates mit Authority-, Receipt-, Ownership- und Sanitizer-Gates Evidenz | Private Hostverträge, keine stabile öffentliche Rust-API | Ownership- und Plattformverträge |
| WebAssembly und WIT Components | Experimentell | Core-Wasm, Component-Runtime und WIT-Fixtures Evidenz | Allgemeines öffentliches Component-Mapping bleibt geschlossen | Ownership- und Plattformverträge |
| Swift und JNI | Experimentell | Begrenzte Apple-Swift- und Android-JNI-Ownership-Verträge Evidenz | Keine allgemeine bidirektionale FFI | Ownership- und Plattformverträge |
| Bestehende Sprachökosysteme | Roadmap | Kein allgemeines Artefakt Evidenz | 100 Prozent Interoperabilität sind Ziel, nicht aktueller Stand | allgemeine Sprache und Ökosystem |
Langfristiges Ziel
Ein Programm soll native, Browser-, Mobile-, Desktop- und bestehende Sprachgrenzen überqueren, ohne Ownership-, Fehler- oder Identitätsfakten zu verlieren. Das bleibt Roadmap-Arbeit, bis jede öffentliche Grenze reproduzierbare Konformitätsevidenz hat.
Die GitHub-Spezifikationen sind die normative Quelle. Diese Seite ist eine datierte Forschungszusammenfassung. GitHub-Repository.
Fragen, ohne Hype beantwortet
Unterstützt Semaprax jedes native Ziel?
Nein. Es gibt begrenzte Evidenz für Native, Wasm, Desktop, iOS und Android. Allgemeiner Support bleibt experimentell oder geplant.
Ist Semaprax vollständig interoperabel?
Nein. Vollständige bidirektionale Interoperabilität ist ein langfristiges Ziel. Aktuelle Evidenz deckt engere C11-, Rust-, WIT-, Swift- und JNI-Grenzen ab.