# 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.