Zum Inhalt

JDL Konsolidierung: Types, Tags, Phantoms, TypeFns, JME-Handle-Semantik und Bootstrap Seed

Status: Konsolidierungsentwurf
Datum: 2026-05-14
Quelle: Online-Specs unter https://specs.iowling.at/

Dieses Paket konsolidiert die semantische Trennung zwischen Wertwelt, Meta-Welt, Bootstrap-Prägung und Runtime-Repräsentation. Es ist als Ersatz-/Patch-Grundlage für die betroffenen Spezifikationskapitel gedacht, nicht als Live-Export der Website.

Leitentscheidung

JDL trennt ab jetzt explizit:

    type       Wertwelt
    tag        Bedeutungs-/Meta-Welt
    phantom    statische Bindung von Bedeutung an Werttypen
    typefn     reine Compile-Time-Funktion auf Type-/Meta-Ebene
    seed       initiale Wahrheitstabelle der Jade VM

Das Ziel ist nicht mehr Syntaxkosmetik, sondern eine saubere Ontologie und ein implementierbarer Bootstrapping-Pfad:

Was zur Laufzeit existiert, ist ein type.
Was nur compile-time Bedeutung trägt, ist ein tag.
Was einen Werttyp statisch mit Bedeutung markiert, ist phantom.
Was Bedeutung berechnet, ist eine typefn.
Was Jade vor der Stdlib zuerst wissen muss, steht im Bootstrap Seed.

Der Bootstrap Seed ist kein ausführbares Modul, kein Plugin und keine Stdlib. Er beschreibt nicht, was Jade tut. Er beschreibt, was Jade zuerst weiß.

Enthaltene Kapitel

  1. 00-ontology-types-tags-phantoms.md
    Grundmodell: Wertwelt, Tag-Welt, Phantom-Brücke.

  2. 01-refinements-meta-tags.md
    Meta-Records, :>, Tags als Profile-Ersatz, Merge-Regeln.

  3. 02-type-system-tags.md
    Typsystem-Auswirkungen: Parameter, Tag-Domains, Phantom-Parameter, Protocols.

  4. 03-typefn-semantics.md
    TypeFns als Compile-Time-Funktionen, nicht als Makros und nicht als Runtime-Code.

  5. 04-axiomatics-truthprofile.md
    Intention rein, Beweis raus. Tags/Meta -> TruthProfile/Labels.

  6. 05-casts-fallible-boundaries.md
    Cast-Modi, try-Blöcke und =? als Boundary-Propagation.

  7. 06-jme-handles-tags.md
    JME-Handles, Tags, Phantom-Policies, keine Pointer in JDL.

  8. 07-compilerdb-tag-subsystem.md
    D-Implementierungsmodell: TagId, TagEngine innerhalb der Type Engine, CompilerDb-Queries.

  9. 08-grammar-sketch.md
    Grammatik-Skizze für tag, type, typefn, :> und Phantom-Parameter.

  10. 09-migration-checklist.md
    Konkrete Liste der alten Konstrukte und Zielschreibweisen.

  11. 10-source-audit.md
    Welche Online-Spec-Bereiche betroffen sind und welche Änderungen daraus folgen.

  12. 11-bootstrap-seeding-praegung.md
    Normatives Kapitel zu Bootstrapping, Seeding und Prägung. Definiert den Bootstrap Seed als initiale Wahrheitstabelle der Jade VM und den Build-Pfad aus jade::core::bootstrap.

  13. 11a-bootstrap-seed-beispiel.md
    Informatives Beispiel einer möglichen Bootstrap-Core-Quelle in JDL.

  14. 11b-bootstrap-seed-nav-patch.md
    MkDocs-/Index-Patchvorschlag für die Einbindung der neuen Bootstrap-Kapitel.

Nicht-Ziele

Dieses Paket ändert keine Website-Dateien live. Es liefert eine konsolidierte Markdown-Fassung, die in die Specs übernommen werden kann. Ja, tragisch: Server schreiben sich noch immer nicht selbst um. Noch.

Der Bootstrap Seed ist ausdrücklich nicht:

- eine zweite Stdlib
- ein normales User-Modul
- ein Runtime-Plugin
- ein Service-System
- ein Ort für Komfort-APIs
- ein magischer Ausweg, um schlechte Ontologie später mit Tabellen zu übermalen

Konsolidierungsstrategie: Von gewachsenen Specs zur Kernel Specification

Die bestehenden JDL/Jade-Spezifikationen sind organisch gewachsen. Das war für Exploration notwendig, ist aber für die Implementierung inzwischen zu unscharf. Einzelne Patches reichen nicht mehr aus, weil mehrere zentrale Konzepte gleichzeitig korrigiert oder neu geschärft wurden:

  • tag statt Fake-type für compile-time Marker
  • phantom als Bindung von compile-time Bedeutung an Werttypen
  • typefn als echte Compile-Time-Berechnung
  • =? als Boundary-Propagation statt zwingendem Function-Return
  • try als fallible Scope
  • JME über typisierte Handles, Policies, Regionen und Tags
  • Casts als gerichtete Relationen mit Modus
  • klare Trennung zwischen Wertwelt, Type-Level und Meta-Level
  • Bootstrap Seed als initiale Wahrheitstabelle vor Stdlib und Userland
  • Seeding/Prägung als initialer Zustand der Type Engine, Memory Engine, VM und Loader-relevanten Registries

Diese Änderungen betreffen nicht nur einzelne Beispiele, sondern die Ontologie der Sprache und den Startzustand der Runtime. Deshalb sollten die bestehenden Specs nicht weiter kleinteilig geflickt werden. Stattdessen braucht es einen harten Neuaufbau aus den stabilen Entscheidungen heraus.

Ziel

Das Ziel ist nicht sofort eine vollständige Sprachbibel, sondern eine implementierbare Kern-Spezifikation:

JDL Kernel Specification v0.1

Diese Kernel Spec soll hart normativ sein und genau das definieren, was Parser, Resolver, Type Engine, CompilerDb, IR, VM, JME und Bootstrap-Initialisierung für eine erste saubere Implementierung brauchen.

Die bisherigen Specs bleiben Materialquelle, Archiv und Inspirationsbasis, aber nicht mehr primäre Struktur.

Vorgehen

1. Alte Specs lesen und markieren
2. Konzepte extrahieren
3. Bootstrap-/Seed-Grenze explizit festlegen
4. Neue normative Struktur schreiben
5. Alte Kapitel nur noch als Materialquelle behandeln
6. Beispiele und Tutorials danach neu aufbauen

Nicht: bestehende Kapitel retten.

Sondern: neue Spezifikation aus den stabilen Entscheidungen rekonstruieren.

Markierung beim Review

Für die manuelle Durchsicht der alten Specs:

GRÜN    = behalten
GELB    = Idee behalten, Syntax oder Begriff veraltet
ROT     = streichen / veraltet
BLAU    = in neues Kapitel verschieben
VIOLETT = offene Designentscheidung

Das Ziel ist, alte Inhalte nicht blind zu übernehmen, sondern ihren semantischen Kern zu extrahieren.

Vorgeschlagene neue Struktur

00-language-ontology.md
    type, tag, phantom, protocol, service, value/type/meta-level

01-bootstrapping-seeding-praegung.md
    Bootstrap Seed, BootstrapSeedBuild, Seeding der Subsysteme, RuntimeStage

02-lexical-and-syntax.md
    Tokens, Keywords, Identifier, Blocks, Operatoren, konkrete Grammatik

03-modules-and-namespaces.md
    Module, imports, visibility, internal, package, pub, reservierte Namespaces

04-types-and-tags.md
    primitive, struct, enum, union, function, tuple, tag, tag enum, generic params, phantom

05-meta-and-refinements.md
    Meta-Records, :>, merge rules, tag meta, conflict rules

06-typefn.md
    Compile-Time-Funktionen, erlaubte Inputs/Outputs, Evaluation, Termination

07-protocols-and-provide.md
    Protocols, provide, methods, derive, coherence, Impl-Scope

08-effects-results-and-boundaries.md
    Result, Option, =?, try blocks, with, fallible boundaries

09-casts-and-conversions.md
    CastTo, lossless/narrowing/try, structural derive, operator ->

10-jme-memory-model.md
    HandleId, Rc, Weak, Arena, Pool, tags, policies, ownership

11-runtime-and-intrinsics.md
    jade::vm, RuntimeBus, Commands, keine rohen Pointer

12-ir-and-lowering.md
    AST -> typed AST -> IR, Extended/Core, desugaring contracts

13-vm-execution-model.md
    Register layout, JadeValue boundaries, bytecode/core instructions

14-compilerdb-and-subsystems.md
    Query API, Type Engine, Tag subsystem, cache/deps, diagnostics

15-stdlib-core.md
    Option, Result, Array, Map, Generator, Collect, Scopeable usw.

Der Bootstrap-Teil steht bewusst früh. Ohne Seed existieren die ersten Typ-/Meta-Wahrheiten nicht, auf denen Stdlib, Plugin Loader und Userland aufbauen. Wer diesen Abschnitt ans Ende schiebt, baut wieder eine hübsche Spezifikation, die beim Starten ins Leere greift. Das wäre literarisch vielleicht interessant, technisch eher weniger.

Einheitliche Kapitelstruktur

Jedes normative Kapitel sollte gleich aufgebaut sein:

Status
Scope
Depends on
Defines
Does not define
Normative rules
Examples
Diagnostics
Open questions

Für Bootstrap-/Subsystem-Kapitel zusätzlich:

Build phase
Runtime stage
Produced artifacts
Consumed descriptors
Subsystem effects
Failure modes

Diese Struktur verhindert, dass Kapitel zu Erzähltexten ohne klare Implementierungsrelevanz werden.

Implementierungspriorität

Die Spezifikation sollte nicht nach Lernreihenfolge, sondern nach Compiler-/Runtime-Pipeline priorisiert werden.

Phase 0: Bootstrap Seed Build
    jade::core::bootstrap Namespace
    BootstrapSeedBuild-Modus
    BootstrapSeedBackend
    bootstrap_seed.d / bootstrap_seed.bin
    Seed-Schema, Versionierung, Hashing

Phase 1: Syntax + AST
    Lexing
    Parser-Kombinator-Regeln
    AST-Knoten
    Module/Imports minimal

Phase 2: Symbolsystem
    SymbolKind: type/tag/protocol/service/typefn/value/module
    Namespace-Auflösung
    reservierte Namespaces
    Sichtbarkeit

Phase 3: Type Engine MVP
    TypeId
    TagId
    ProtocolId
    MetaRecord
    typefn evaluation minimal
    :> merge
    TruthProfile minimal
    Seed-Import in TypeEngine

Phase 4: Bootstrap Initializer + Subsystem Seeding
    RuntimeStage: Constructed -> Seeded
    TypeEngine.seed(...)
    MemoryEngine.seed(...)
    VM.seed(...)
    SymbolRegistry.seed(...)
    IntrinsicRegistry.seed(...)

Phase 5: Stdlib Loader MVP
    Plugin Loader startet erst nach Seed
    Stdlib als privilegiertes Plugin
    Option/Result/Diagnostics aus Seed verfügbar
    normale Protocols/Provides erst nach Stdlib

Phase 6: Werte und Runtime-MVP
    struct/enum
    functions
    Result/Option
    =?
    simple with/try boundaries

Phase 7: JME MVP
    HandleId
    generation counter
    Rc
    Weak.upgrade()
    Arena basics
    Memory policies

Phase 8: IR + VM
    Typed AST lowering
    Core bytecode
    Register layout
    JadeValue only at boundaries

Diese Reihenfolge verhindert, dass spätere High-Level-Konstrukte spezifiziert werden, bevor die Grundbegriffe und der Startzustand stabil sind.

Definition of Ready für die Implementierung

Mit der Implementierung sollte erst begonnen werden, wenn diese Punkte normativ fixiert sind:

1. Lexical grammar und Parser-Regeln für:
   type, tag, tag enum, typefn, :>, protocol, provide, def, val/var

2. AST-Struktur für:
   TypeDecl, TagDecl, TypeFnDecl, MetaRecord, RefinementChain

3. SymbolKinds:
   Type, Tag, TagVariant, Protocol, Service, TypeFn, Value, Module

4. Type-Level Value Modell:
   TypeId, TagId, MetaRecordId, ProtocolId, Literal

5. typefn Evaluation:
   Inputs, Outputs, keine Runtime-Werte, deterministisch, cachebar

6. Meta-Merge-Regeln:
   Konflikt vs Override vs Default

7. Minimaler TruthProfile-Algorithmus:
   proven/excluded/unproven, Provenienz, Konflikte

8. Bootstrap Seed:
   reservierter Namespace jade::core::bootstrap
   BootstrapSeedBuild-Modus
   BootstrapSeedBackend
   Seed-Schema und Versionierung
   PrimitiveDescriptoren
   minimale TypeDescriptoren
   Tag-/Meta-Domänen
   Intrinsic-/PrimitiveOp-IDs, soweit nötig

9. Bootstrap Initializer:
   RuntimeStage constructed/seeded/stdlibLoaded/ready
   Seeding-Reihenfolge der Subsysteme
   harte Fehler bei Zugriff vor Seed
   Trennung BootstrapInitializer vs RuntimeBus

10. JME-MVP:
   HandleId, generation, Rc, Weak, ArenaTag, Memory(Arena[X])

Wenn diese Punkte nicht klar sind, entsteht die Implementierung auf Sand. Sehr schön vielleicht, aber die Statik wird beleidigend.

Bootstrap Boundary

Der Bootstrap Seed bildet eine eigene Grenze zwischen Jade als D-Engine und Jade als JDL-Welt.

D-Engine vor Seed:
    VM-Objekte existieren.
    Subsysteme existieren.
    Es gibt aber noch keine initiale Jade-Wahrheit.

Nach Seed:
    TypeEngine kennt Primitive, Core-Typen und minimale Meta-Domänen.
    MemoryEngine kennt initiale Layout-/Representation-Informationen.
    VM kennt minimale Primitive-/Intrinsic-IDs.
    Plugin Loader kann die Stdlib laden.

Nach Stdlib:
    Protocols, Provides, Services, Effects, Collections und Userland werden regulär verfügbar.

Der Seed ist damit kein Feature für Benutzer. Er ist die Prägung der Maschine.

Normativ:

Der Bootstrap Seed wird beim Benutzer nicht kompiliert.
Er wird beim Jade-Team-Build erzeugt und in die VM eingebettet.
Der Benutzer kann den Namespace jade::core::bootstrap nicht definieren, importieren, erweitern oder überschreiben.

Zentrale Designachse

Die neue Kernel Spec muss konsequent zwischen Wertwelt, Type-Level, Meta-Level und Seed-Level trennen:

type
    Wertwelt.
    Von einem type können Werte existieren.

tag
    Bedeutungs-/Meta-Welt.
    Keine Werte, kein Layout, keine Implementierung.

phantom
    Bindet compile-time Bedeutung an einen Werttyp,
    ohne Runtime-Repräsentation.

typefn
    Compile-Time-Funktion.
    Berechnet Typen, Tags, Meta-Records, Literale oder andere Type-Level-Werte.

:>
    Wendet Meta auf eine Definition an.

Closure / TruthProfile
    Beweist aus Meta und Struktur konkrete Garantien.

Bootstrap Seed
    Initiale Wahrheitstabelle.
    Befüllt die minimalen Subsystemtabellen, bevor Stdlib oder Userland existieren.

Warum ein Neuaufbau nötig ist

Die aktuellen Änderungen sind keine kosmetischen Patches. Sie ändern die Grundordnung der Sprache.

Wenn diese Konzepte nur in bestehende Kapitel hineingeflickt werden, bleiben alte Begriffe und Beispiele als Altlasten erhalten. Das würde die Implementierung unnötig erschweren und später zu widersprüchlichen Compilerregeln führen.

Der Neuaufbau soll verhindern, dass Dinge wie RequestArena, UserPhase, TaskLocal oder JME-Policies weiterhin als scheinbare types behandelt werden, obwohl sie eigentlich compile-time Bedeutungen sind.

Der Bootstrap-Teil verhindert zusätzlich, dass unklar bleibt, woher TypeEngine, MemoryEngine, VM und Plugin Loader ihre ersten gemeinsamen Begriffe bekommen.

Kurzfassung

Nicht alles, was der Compiler wissen muss, ist ein type.
Nicht alles, was Jade zuerst wissen muss, ist Stdlib.

Types beschreiben Werte.
Tags beschreiben Bedeutungen.
Phantoms binden Bedeutungen an Werttypen.
TypeFns berechnen Bedeutungen.
Meta-Records speichern Bedeutungen.
Closure beweist Garantien.
Der Bootstrap Seed prägt die Maschine mit ihren ersten Wahrheiten.
JME setzt Runtime-Sicherheit über Handles durch.

Die Kernel Spec muss diese Ordnung zuerst hart festlegen. Alles andere baut darauf auf.