Michael Schimmel
58 lines
3.7 KiB
Markdown
58 lines
3.7 KiB
Markdown
# 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. |