RustAst/docs/Zustand 3.md

Projekt-Protokoll: Finalisierung des Sprachdesigns für Zustand

• Datum: 09. Oktober 2025
• Zeit: 12:26 CEST

Motivation

Aufbauend auf dem initialen Entwurf eines sicheren Zustands-Modells geht es in diesem Schritt um die Konkretisierung und Verfeinerung des Sprachdesigns. Die Diskussion hat gezeigt, dass die Wahl der Schlüsselwörter (def, let) und die exakte Definition der Scope-Regeln entscheidend für die Intuivität und Sicherheit der Sprache sind. Ziel dieses Dokuments ist es, die finalen Entscheidungen festzuhalten.

Ziel

1. Etablierung unmissverständlicher Schlüsselwörter: Die finalen Namen für die drei Zustands-Konstrukte (atom, var, let) sollen deren Semantik klar und deutlich widerspiegeln.
2. Festlegung der Scope-Regeln: Die Rolle des (do)-Blocks als primärer Scope-erzeugender Mechanismus für lokalen Zustand wird formalisiert.
3. Definition der Unveränderlichkeits-Garantie: Die Regeln für die Compile-Zeit-Überprüfung der Unveränderlichkeit von let-Bindungen werden festgelegt.

Ergebnis: Das finale Drei-Säulen-Modell für Zustand

Wir haben uns auf ein klares Modell mit drei spezialisierten Konstrukten für die Zustandsverwaltung geeinigt, das maximale Sicherheit bei gleichzeitig hoher Flexibilität und Verständlichkeit bietet.

1. Die drei Konstrukte

Die folgende Tabelle fasst die Eigenschaften der drei finalen Konstrukte zusammen:

Konstrukt	Geltungsbereich	Veränderlichkeit	Threadsicherheit
atom	Global / Geteilt	Veränderlich (atomar)	Ja (Design-Ziel)
var	Lokal (do-Block)	Veränderlich	Nein (by Design)
let	Lokal (do-Block)	Unveränderlich	Ja (da unveränderlich)

2. Syntaktische Form

Alle drei Konstrukte folgen einer einheitlichen, einfachen Syntax für die Deklaration und optionale Initialisierung:

• (atom symbol initial-value)
• (var symbol initial-value)
• (let symbol initial-value)

3. Implikation für (do)

Der (do)-Block (IBlockExpressionNode) wird zum zentralen und einzigen Mechanismus für die Erzeugung lexikalischer Geltungsbereiche für lokalen Zustand (var und let). Jedes Vorkommen von (do ...) öffnet einen neuen Scope, der nach Abarbeitung des Blocks wieder zerstört wird. Dies ermöglicht ein intuitives, imperativ anmutendes Programmieren mit klar definierten Lebenszeiten für lokale Variablen.

---

Nächste Schritte (Todo)

1. Parser anpassen:

   • Die Schlüsselwörter def und let werden durch atom, var und let ersetzt.
   • Alle drei Konstrukte werden initial zum selben IVariableDeclarationNode geparst. Eine Unterscheidung, um welches Konstrukt es sich handelt, wird im Binder getroffen.

2. Binder anpassen (Kernaufgabe):

   • do-Scoping: VisitBlockExpression wird so erweitert, dass es bei jedem Aufruf einen neuen Scope (EnterScope/ExitScope) verwaltet.
   • Symbol-Verfolgung: Der Binder muss für jede deklarierte Variable speichern, ob sie via atom, var oder let erzeugt wurde.
   • Unveränderlichkeits-Prüfung: Beim Besuch eines (assign ...)-Knotens (VisitAssignment) muss der Binder prüfen, ob die Zielvariable als let deklariert wurde. Wenn ja, wird ein Compile-Fehler ausgelöst.
   • Escape Analysis verfeinern: Die Sicherheitsprüfung wird so angepasst, dass sie nur noch bei Closures greift, die eine var-Variable fangen. Closures, die let-Variablen fangen, sind immer sicher.

3. RTL & Evaluator anpassen:

   • Die Laufzeitlogik für def wird zur Implementierung für (atom ...) und erzeugt einen atomaren Container.
   • Die RTL wird um die Funktionen deref, reset! und swap! erweitert.