Zum Inhalt

Nachtrag — Entscheidungen ohne Dokument

Status: Sammelstelle, Arbeitsstand Datum: 2026-10-02 Zweck: Entscheidungen und Vorschläge aus den Arbeitsgesprächen, die bisher in keinem veröffentlichten Dokument stehen — mit dem Dokument, in das sie gehören.

Wie dieses Dokument zu lesen ist

Jeder Eintrag nennt, was entschieden oder vorgeschlagen ist, und wohin er gehört. Wird ein Eintrag in sein Zieldokument übernommen, fliegt er hier raus. Ist die Liste leer, hat das Dokument seinen Zweck erfüllt.

Marke Bedeutung
[E] entschieden
[V] Vorschlag, nicht entschieden
[O] offen

Einige Einträge stammen aus Gesprächen, deren Einzelheiten nur in Zusammenfassung erhalten sind. Sie sind mit Einzelheiten nicht erhalten markiert. Dort ist das Zieldokument der Ort, an dem die Einzelheiten neu ausgearbeitet werden, nicht dieser Nachtrag.

Bereits übernommen und deshalb hier nicht mehr aufgeführt:

Descriptor-Kopf, Excerpt, Selektion und Projektion   wie-jade-uebersetzt §4, jdl-blueprint-spec 0.5.0
Verweise über Hash, Zulassung über Name und Hash     wie-jade-uebersetzt §4.9
Fragen als Daten, Schema als Daten                   wie-jade-uebersetzt §3.7
Speicherbudget und Reset langlebiger Meta-Contexts   wie-jade-uebersetzt §11
Row und Pipe-Liste                                   jdl-blueprint-spec 0.5.0 §5.4
Meta-Phase: Schreibweise, Allokation, Teilsprache    jdl-meta-phase 0.3.0
Partielle Applikation und Call(f)                    jdl-partielle-applikation 0.1.3
Engine-Protokoll, Excerpt[Desc], Träger, kein api    jdl-blueprint-spec 0.5.1 §9.1, §9.2
ContextApi als internes Gate                         wie-jade-ausfuehrt §5.2
Verweise im Excerpt über den Excerpt-Hash            wie-jade-uebersetzt §4.4, jdl-blueprint-spec 0.5.2 §7.3
Eine Engine je Blueprint-Typ                         jdl-blueprint-spec 0.5.2 §9.4
Verschachtelte Blueprints in der Pipe-Liste          jdl-blueprint-spec 0.5.2 §3.7
Call(f) liefert einen TypePatch                      jdl-partielle-applikation 0.1.3 §3.2
Meta-Code ruft Funktionen über den Row-Test auf      jdl-meta-phase 0.3.1 §3.4
Rumpf verweist auf seinen Export                     wie-jade-uebersetzt §4.9, jdl-blueprint-spec 0.5.2 §7.3

A. Syntax

Ziel: jdl-sprachreferenz, 08-grammar-sketch

A1 := bindet mit abgeleitetem Typ [E]. x := wert ist eine Bindung, deren Typ aus dem Wert abgeleitet wird. Nur für Werte, nicht für def: Eine Funktion ist kein Wert, der an dieser Stelle gebunden wird. Die Sprachreferenz §2.1 kennt bisher nur val und var.

A2 Zeilenfortsetzung mit führendem Punkt [E]. Zeilenende trennt (Sprachreferenz §1.2). Beginnt die nächste Zeile mit ., setzt sie die vorige fort. Das trägt verkettete Aufrufe wie bei Buildern (wie-jade-uebersetzt §3.7). Dazu gilt eine Regel nach dem Vorbild von Go: Endet eine Zeile offensichtlich unvollständig, trennt ihr Ende nicht. Die Sprachreferenz nennt die Fortsetzung bisher nicht.

A3 Klammern und Tupel [O]. In den Gesprächen wurde eine Falle benannt: Runde Klammern über mehrere Zeilen können mit einem Tupel verwechselt werden, wenn Zeilenende trennt. Einzelheiten nicht erhalten.

A4 Geschweifte Klammern bleiben Begrenzer [E]. Blöcke, Rümpfe und Record-Formen stehen in { }. Sie werden nicht durch Einrückung ersetzt.

A5 * heißt „alle“ [E]. Die Bedeutung ist an jeder Stelle dieselbe: .services.* (alle Services), Throw[*] (alle Fehler), ->{*} (alle Row-Elemente). Wo * stehen darf, regelt die jeweilige Stelle: In einer Row nur modulintern (Regel R-4), in einer Pipe-Liste nur unter einer Gruppe, nie als | .* | (jdl-blueprint-spec §5.4, BP-26).

A6 _ hat drei Rollen [E]. Welche gilt, ergibt sich aus der Stelle:

match-Arm          _ => ...                  Auffangarm: passt auf alles
Argument           send(to = _, ...)         Lücke einer partiellen Applikation
links vom =        _ = doSomething()         Ergebnis bewusst verwerfen

Beim Verwerfen fällt nur der Wert weg. Die Row des Aufrufs gilt weiter: Ein möglicher Fehler muss trotzdem behandelt werden, und die benötigten Services müssen da sein. Hält der Wert eine Resource, wird sie sofort freigegeben.

[O] Ist es ein Fehler, ein Ergebnis ohne _ = einfach liegen zu lassen? Nach dem Leitprinzip „kein Automatismus“ wäre das naheliegend: Wer ein Ergebnis ignoriert, sagt es. Ausgenommen wären Funktionen mit Rückgabetyp Unit.

[V] _ = f(x = _) baut eine partielle Applikation und verwirft sie sofort. Das ist zulässig, aber sinnlos; eine Warnung wäre angebracht.

A7 Pipe-Liste | ... | — steht jetzt in jdl-blueprint-spec §5.4. Die Sprachreferenz §5.2 führt | noch mit unsicherem Notationsstatus und sollte darauf verweisen.

A8 Kurze Patch-Namen [E]. Die Patch-Arten heißen nach dem, was sie anlegen oder ändern, ohne „Descriptor“ im Namen: TypePatch, ProvidePatch, RefinementPatch, MetaPatch, DiagnosticPatch. Umbenannt ist damit nur TypeDescriptorPatch → TypePatch. Ein Patch wirkt immer auf die CompilerDB, nie auf ein Artefakt; „Descriptor“ im Namen sagte also nichts, was nicht ohnehin gilt. Ziel: jade-compiler-db-spec §9.3; jdl-typefn-spec §5.2 ist veraltet und führt den alten Namen ebenfalls.

B. Einstiegspunkte und Contexts

Ziel: v2/design-context-entrypoints, v2/spec-context-model-refactored

B1 main ist die Haustür [E]. main hat eine leere Row und keine Auswahllogik. Es nimmt die Argumente als Daten entgegen, baut per with den Root-Context über dessen ContextEngine auf und reicht an run weiter.

[O] ret innerhalb eines with verlässt nur den with-Block. Wie der Rückgabewert von run aus main herauskommt — Wert binden oder die with-Regel ändern —, ist offen.

B2 Der Root-Context routet [E]. Welcher Einstiegspunkt gemeint ist, entscheidet der Root-Context sichtbar in run, nicht ein versteckter Dispatcher davor.

[O] design-context-entrypoints D.6 trennt die Wahl des Einstiegspunkts von den Startdaten. B2 gibt diese Trennung auf. Ob D.6 fällt oder run zusätzlich ein getrenntes Ziel erhält, ist offen.

B3 Die ContextEngine ist eine RuntimeEngine [E]. describe baut in der Meta-Phase den ContextDescriptor, instantiate zur Laufzeit aus dessen Excerpt die Domäne; instantiate kann mit einem Engine-Fehler scheitern. Das Context-Modell §2 muss nachziehen.

B4 Zur Laufzeit wird nie beschrieben [E]. Neue Contexts kommen zur Laufzeit nur als fertige Artefakte: laden, zulassen über den Hash der erwarteten Schnittstelle, aktivieren innerhalb eines Envelopes. Services des Elternteils erhält ein geladener Context nur über ausdrückliches Parent-Expose.

B5 Kein scope, kein entry im Context [E]. Das diskutierte Feld scope entfällt; seine Aufgabe übernehmen Row und Pipe-Liste. Einstiegspunkte sind keine Felder des Contexts.

B6 Services und Autorität getrennt [E]. Services stehen im Feld services, nach Typ geordnet. Konkrete Autorität — welche Datenbank, welcher Socket — steht in den Resource-Bindungen. Ein Service-Name allein erzeugt keine Autorität.

Hinweis: Die Projektnotiz notiz-entrypoints-arbeitsstand vom 2026-09-25 ist in B3 und B5 überholt.

C. Envelope

Ziel: v2/addendum-context-meta-v0.2

C1 Das Envelope verengt nur [E]. Es ist eine Hülle um einen oder mehrere Contexts und legt Maschinenwahrheiten fest, die höchstens enger werden dürfen: Dateien, Netz, Speicher, Ort der Ausführung. Es schreibt nie in einen Context hinein. Es ist für einen Context, was ein Context für eine Funktion ist.

C2 Bedarf gegen Erlaubnis beim Start [E]. Der Context bringt seinen Bedarf, das Envelope die Erlaubnis. Passt der Bedarf nicht, wird der Start abgelehnt — nicht erst der erste Zugriff. Ohne Angabe erlaubt ein Envelope genau den Bedarf [V].

C3 Was nicht ins Envelope gehört [E]. Fairness und Scheduler-Konfiguration stehen im ContextDescriptor. Es gibt einen Scheduler pro Prozess, und er gehört Ring 0. Platzierung darf das Envelope nur als Einschränkung angeben, nicht entscheiden.

C4 Algebra [V]. Mehrere Envelopes werden mit denselben Arten zusammengeführt wie Beiträge von Components: engste gewinnt, genau einer, sammeln (jdl-blueprint-spec §4.10). Einzelheiten nicht erhalten.

C5 Speicherbudget für Meta-Contexts — steht in wie-jade-uebersetzt §11. Das Envelope ist dort der Ort, an dem das Budget eines Sprachservers oder einer REPL gesetzt wird.

D. Bindungen, Start und Geheimnisse

Ziel: v2/spec-resource-model, eine noch zu schreibende Spec der Startphase, jdl-storage-memoryregion-empfehlung

D1 Umgebungsabhängiges steht nicht im Artefakt [E]. Resource-Bindungen sind im Artefakt offen und werden bei der Zulassung hergestellt. Die Werte dafür liegen außerhalb, eine Angabe pro Umgebung. Ein eigener Mechanismus für Startwerte (Start[T]) ist verworfen. Gewöhnliche Konfiguration ist Laufzeitdaten. Beschrieben in wie-jade-ausfuehrt §11.2.

D2 Reihenfolge beim Start [E]. Laden, Bindungen herstellen, Bedarf berechnen, gegen das Envelope prüfen, Sandbox des Betriebssystems ableiten, festschreiben, erst dann JDL-Code. Beschrieben in wie-jade-ausfuehrt §11.3.

[O] Format der Bindungsangaben, wer sie liefert und wie sie bei der Aktivierung an die Services gelangen, die in den Rows stehen. instantiate bekommt sie nicht als Parameter.

D3 Geheimnisse [E] für den eigenen Typ, [V] für die Einzelheiten. Zwei Typen: SecretRef ist ein serialisierbarer Verweis und darf in Blueprints und Artefakten stehen. Secret existiert nur zur Laufzeit, wird beim Freigeben überschrieben und darf nie Teil einer Fehler-Nutzlast (Throw) sein. Aufgelöst wird ein Verweis über einen Secrets-Service.

D4 Pools [O]. Speicher-Pool und Resource-Pool sind verschiedene Dinge. Für den Trusted Core sind drei Punkte festgehalten:

  • Generationszähler bei Wiederverwendung eines Slots, damit ein veralteter Handle erkannt wird.
  • Rückgabe geliehener Resources nach einem Trap, wenn der JDL-Code dafür nicht mehr läuft.
  • Mindest- und Höchstgröße eines Pools.

Einzelheiten nicht erhalten.

E. Typen und Werte

Ziel: Konsolidierung/00-ontology-types-tags-phantoms, Notizen/jdl-types-tags-phantoms, Notizen/jdl-runtime-descriptor-context-engine-notiz-v2

E1 Zustände über Tag und Phantom [E]. Eine Menge von Zuständen ist ein tag, kein type. Ein Typ trägt seinen Zustand als Phantom-Parameter, etwa eine Bestellung, die nur im Zustand „bezahlt“ bestätigt werden kann. Kommen Zustände zur Laufzeit von außen, etwa aus einer Datenbank, liest man sie in ein gewöhnliches enum und prüft von dort in den Phantom-Typ.

E2 Verbrauchender Parametermodus [O]. Zustandsübergänge über Phantome brauchen einen Parameter, der den alten Wert verbraucht, damit man ihn nach dem Übergang nicht weiter benutzt. Den gibt es in JDL noch nicht.

E3 Function Unions [V]. Eine geschlossene Menge von Operationen, bei der ein Wert eine Anfrage an eine davon ist. Vorschlag für die Schreibweise: ein union, dessen Varianten aus Funktionen gebildet werden. Die Notiz §6 muss an die aktuelle Syntax angepasst werden: geschweifte Klammern, Throw, Unit, eine Row je Variante.

E4 Table[K, V] [O]. Ein Record mit genau einem Eintrag je Wert eines Enums K, in der Meta-Phase gebaut. Offen ist, ob es ein eingebauter Typ ist oder in Nephrit liegt.

E5 CallGraph [V]. Ein CallGraph ist ein Blueprint aus Call-Knoten (jdl-partielle-applikation §3) und ein Thema für Nephrit, nicht für die Sprache. Er lohnt nur dort, wo Ausführung dauerhaft, schrittweise wiederholbar, verteilt oder geplant sein muss. Das wäre die Antwort auf den offenen Punkt 5 der Blueprint-Spec; der Vorteil gegenüber gewöhnlichem Code ist aber noch nicht belegt.

Wird aus einem CallGraph ein Gesamtbedarf abgeleitet, dann je Ausführungsdomäne, nicht als eine große Row für den ganzen Graphen. Nur wenn alle Knoten im selben Context laufen, ist der Bedarf die Vereinigung ihrer Rows. Ein CallGraph beschreibt Abhängigkeiten zwischen Arbeit; er behauptet nicht, dass diese Arbeit dieselbe Autoritätsdomäne teilt.

Orchestrierung wie Wiederholen oder Zeitlimits gehört als Refinement an den Blueprint, den Call erzeugt (jdl-blueprint-spec BP-10), nicht in eigene Knotentypen. Wer die von der CallEngine gelieferte Funktion später mit den offenen Argumenten aufruft, ist Sache von Nephrit, nicht des Schedulers in Ring 0: Der kennt keine Jobs, er bekommt nur ausführbare Arbeit.

F. Blueprints

Ziel: jdl-blueprint-spec

F1 Blueprint-lokale Formen [E]. Ein Blueprint darf eigene enum-, union- und record-Formen enthalten. Sie verhalten sich im Prinzip wie außerhalb, folgen aber Regeln der Umgebung; empfohlen ist eine strikte Teilmenge. & auf einer Enum-Variante ist nicht vorgesehen; & füllt den Record, den eine Variante trägt.

F2 Variante ersetzen oder zusammenführen [O]. Wählt ein Profil eine andere Variante eines blueprint-lokalen Enums, ist offen, ob die Werte der alten Variante verworfen oder, soweit passend, übernommen werden.

F3 Laufzeitwerte blueprint-lokaler Formen [O]. Wie ein Enum mit Nutzlast im Descriptor so dargestellt wird, dass Ring 0 es ohne Kenntnis des Nutzertyps lesen kann. Kandidat sind die Rollen von RecordShape; mit „Schema als Daten“ (wie-jade-uebersetzt §3.7.4) gibt es einen zweiten.

G. Engines

Ziel: jdl-blueprint-spec §9, Konsolidierung/00-ontology-types-tags-phantoms, jade-compiler-db-spec §9

Was davon in die Blueprint-Spec 0.5.1 eingeflossen ist, steht dort. Hier nur, was ein anderes Zieldokument hat oder noch offen ist.

G1 Das leere Struct [E]. Ein Struct ohne Felder hat genau einen Wert und belegt keinen Speicher. Das gehört als Eigenschaft in die Ontologie bei struct, damit der Träger einer Engine kein Grenzfall ist, sondern eine beschriebene Eigenschaft. In der VM braucht so ein Wert weder Register noch Handle.

G2 Form des Engine-Protokolls [O]. Bei der Benutzung wählt man nur den Blueprint. Desc, Out und die Row legt die Implementierung fest. Wie das Protokoll das deklariert, ist offen: als gewöhnliche Typparameter, deren Werte der Compiler aus den Signaturen abliest; als von der Implementierung festgelegte Typen wie in Rust; oder als associated effects wie in Flix (PLDI 2024). Daran hängt eine Sprachfrage: ob Protokolle Typen und Rows enthalten können, die erst die Implementierung bestimmt.

G3 Rows als Typen [O]. Diskutiert wurde, Rows als eigene Art auf Typebene zu führen, damit man sie benennen und übergeben kann, etwa als tag ShopNeeds = {...} mit durchsichtigem Alias. Bewusst offengelassen, bis zur Implementierung: Es wirkt noch künstlich. Fest steht nur, dass ein Row-Name, falls es ihn gibt, durchsichtig sein muss und keine Autorität verstecken darf.

G4 Herkunft eines Feldwerts [O]. Die Vorrangregel der Komposition braucht eine Anfrage an die CompilerDB, ob ein Feld gesetzt wurde oder seine Vorgabe trägt (jdl-blueprint-spec §4.7, offener Punkt 20). Ziel: der Anfragekatalog der CompilerDB.

G5 Diagnosen melden ohne Abbruch [O]. Ein describe, das auf Hilfsfunktionen aufgeteilt ist, kann Fehler nur sammeln, wenn es einen Weg gibt, eine Diagnose zu melden, ohne abzubrechen. Dieselbe Lücke betrifft Warnungen bei erfolgreichem describe (jdl-blueprint-spec offener Punkt 9). Die Meldungen müssen im Ergebnis landen, nicht in einer Seitenablage.

H. Bridge

Ziel: v2/spec-context-bridge, das damit zur Spec der Exchange wird

H1 Zwei Schichten [E]. „Bridge“ ist das Wort für das Ganze, so wie „das Netz“: der Weg von Information zwischen Contexts, gleich welcher Entfernung. Darunter liegen zwei Schichten:

Bridge          was der Benutzer sieht und deklariert
  Exchange      Bedeutung: Anschlüsse, Rollen, Einhäng-Rechte, Codec, Fehler
  Fabric        Mechanik: Transport über jede Entfernung, wie das Fabric einer CPU

Das Fabric gehört nach Ring 0, die Typen der Exchange nach JDL. Die bisherige Bridge als Verbindung zweier Contexts ist ein Sonderfall: eine Exchange mit zwei Teilnehmern.

H2 Adressiert wird der Anschluss, nie der Ort [E]. Ein Context ruft einen getypten Anschluss an, nicht „Knoten 3“. Wo der Abnehmer sitzt, weiß nur die Bridge. Anschlüsse werden über Name und Hash identifiziert und sind damit auf jedem Knoten dieselben.

H3 Begriffe [V]. Vorschläge, noch nicht bestätigt:

Line              der getypte Anschluss, eine Function Union
Endpoint          wo ein Context an einer Line hängt (Begriff aus der Bridge-Spec)
attach, detach    einhängen, aushängen
calls, answers    Rolle: ruft an, nimmt ab
.single           genau einer nimmt ab; ein zweiter wird beim Einhängen abgelehnt
.any              einer von mehreren nimmt ab
.all              alle nehmen ab
Trunk             Verbindung zwischen den Fabrics zweier Knoten

„Port“ ist für die Exchange ausgeschlossen, weil der RuntimeBus das Wort schon benutzt. Ebenso vergeben oder belastet: Channel, Slot, Hook, Provider, Service, Socket, Topic.

H4 Für den aufrufenden Code ist eine Line ein Service [V]. Wer eine Line anruft, führt sie in services und in seiner Row wie jeden anderen Service. Ob die Implementierung lokal ist oder über die Exchange läuft, entscheidet die Bindung. Neu ist nur die Angabe, wo eine Line abgenommen wird, und im Eltern-Context, wer an welchen Lines rufen oder abnehmen darf.

H5 Unkaputtbar [E] für das Ziel, [V] für die Regeln. Jeder Konfigurationsfehler ist entweder nicht hinschreibbar oder wird vor dem Start abgelehnt. Zur Laufzeit darf eine Bridge nur scheitern, weil die Gegenseite wirklich fehlt. Dafür:

  • Die Richtung ergibt sich daraus, wer abnimmt; es gibt keine Verdrahtung von Hand.
  • Die Art einer Line legt fest, wie viele abnehmen dürfen; Verstöße fallen beim Einhängen auf.
  • Jede Funktion einer Line trägt Throw[BridgeError] in ihrer Row, geprüft beim Übersetzen.
  • Kein Aufruf ohne Zeitgrenze; unbegrenztes Warten muss ausdrücklich verlangt werden.
  • Synchrone Kreise zwischen statisch bekannten Contexts sind ein Fehler beim Übersetzen.
  • Nimmt niemand ab, bekommt der Anrufer ein BridgeError und wartet nicht.

H6 Einhängen ist Autorität [V]. Das Recht, sich an eine bestimmte Line in einer bestimmten Rolle zu hängen, ist ein Handle und kommt nur über eine Bindung oder über Parent-Expose. Ring 0 prüft es beim Einhängen. Ohne diese Regel wäre die Exchange ein globaler Bus. Abschwächung nach Regel B-5 von spec-context-bridge gilt pro Line.

H7 Eine Zusage für jede Entfernung [V]. Eine Line verspricht über jede Entfernung nur, was sie auch über die größte halten kann. Lokal darf sie schneller sein, aber nie mehr versprechen. Festzulegen sind Reihenfolge (pro Sender) und Zustellung (höchstens einmal oder mindestens einmal, je Line). Getestet wird über die Entfernung mock.

H8 Resources bleiben beim Besitzer [E], die Regeln für den Trusted Core [V]. Eine Resource wandert nicht; Operationen wandern zu ihr, Ergebnisse kommen als Werte zurück. Der Code hält dabei keine fremden Handles, sondern benutzt Services, deren Implementierung lokal oder über die Bridge arbeitet.

Ausnahme im Fabric [E]. Bei kurzer Entfernung (local, thread) darf das Fabric eine Resource intern verschieben, etwa eine angenommene Verbindung an einen Worker. Für den Code ist das unsichtbar und ändert keine Zusage (H7). Beschrieben in wie-jade-ausfuehrt §5.4.

Für den Trusted Core:

  • Ein Verweis aus der Ferne trägt Knoten, Slot und Generation; der Besitzer prüft die Generation bei jeder Operation.
  • Ein Lease über Entfernung verfällt, wenn er nicht erneuert wird. Lease ist damit Mechanik des Fabric, kein Weg für den Code.
  • Verschiebt das Fabric, ist das Autoritätsübertragung; die Zielseite trägt nie mehr Autorität als die Quelle.

Widerspruch: spec-context-bridge §1.4 und §2 (B-3, B-5) und spec-context-model-refactored X-10 führen Lease, Transfer und geteilte Handles noch als Wege für den Code. Sie müssen nachziehen.

Änderungsprotokoll

2026-10-02, Patch-Namen — A8 neu: TypeDescriptorPatch heißt TypePatch.

2026-10-02, Kohärenzprüfung — A5: * hat überall dieselbe Bedeutung, wo es stehen darf, regelt die Stelle; in der Pipe-Liste nur unter einer Gruppe. H8: Ausnahme im Fabric für kurze Entfernungen, Lease als Mechanik des Fabric, Widerspruch zu spec-context-bridge und spec-context-model-refactored benannt. H6: Verweis auf B-5 eindeutig gemacht. B3: instantiate liest den Excerpt. D2: offene Frage ohne das alte Parametermodell. Liste der übernommenen Punkte um die Entscheidungen dieses Tages erweitert. A7 und C5 bleiben bewusst stehen: Ihr Rest betrifft die Sprachreferenz beziehungsweise die Envelope-Spec, die noch nachziehen müssen.

2026-10-02 — Abschnitte G (Engines) und H (Bridge) ergänzt. Liste der übernommenen Punkte um Blueprint-Spec 0.5.1 und wie-jade-ausfuehrt §5.2 erweitert.

2026-09-29 — Erste Fassung. Gesammelt aus den Arbeitsgesprächen bis 2026-09-29 und abgeglichen mit der veröffentlichten Sprachreferenz 0.1.0 und design-context-entrypoints, die keinen dieser Punkte enthalten. Nachträglich: A6 um die dritte Rolle von _ ergänzt (Ergebnis verwerfen).