Michael Schimmel
124 lines
4.9 KiB
Markdown
124 lines
4.9 KiB
Markdown
# Einführung von N-dimensionalen Tupel-Strukturen und Typ-Unification
|
|
|
|
**Datum:** 04.01.2026
|
|
|
|
**Status:** Design abgeschlossen / Vorbereitung der Implementierung
|
|
|
|
---
|
|
|
|
## 1. Motivation
|
|
|
|
In der bisherigen Architektur wurden Argumentlisten, Parameterlisten und Datenstrukturen (Records/Series) als getrennte Konzepte behandelt. Dies führt zu unnötigem Overhead durch "Boxing" (Einpacken von Werten in Objekte) und erschwert die statische Optimierung mathematischer Operationen.
|
|
|
|
**Das Ziel dieser Erweiterung:**
|
|
|
|
* **Vereinheitlichung:** Alles, was eine feste Sequenz von Daten ist, wird intern ein **Tupel**.
|
|
* **Performance:** Durch präzise statische Analyse der "Shape" (Form) und des Inhalts sollen Daten unboxed (als reine Value-Types) im Speicher liegen können.
|
|
* **Monomorphisierung:** Der Compiler soll hochoptimierten Maschinencode (SIMD) erzeugen können, sobald er erkennt, dass Datenstrukturen "rechteckig" und homogen sind.
|
|
|
|
---
|
|
|
|
## 2. Architekturbeschreibung
|
|
|
|
### 2.1 Die Typ-Hierarchie (`IStaticType`)
|
|
|
|
Wir führen eine rekursive Inferenz-Logik im `TypeChecker` ein, die den am besten passenden statischen Typ ermittelt:
|
|
|
|
1. **`stTuple`**: Der Basisfall. Eine heterogene Sequenz fester Länge (z. B. `[1 "Text"]`). Jeder Slot hat seinen eigenen statischen Typ.
|
|
2. **`stVector`**: Ein Spezialfall des Tupels. Alle Elemente besitzen den **identischen** statischen Typ (Homogenität). Dies erlaubt den typsicheren Zugriff über variable Indizes.
|
|
3. **`stMatrix`**: Ein rekursiver Spezialfall des Vektors. Ein Vektor, dessen Elemente wiederum Vektoren oder Matrizen sind, sofern sie eine **identische Shape** (Dimensionen) aufweisen ("Rechteckigkeit").
|
|
|
|
### 2.2 Die "Scalar-Pure" Optimierung
|
|
|
|
Dies ist eine rein interne Optimierung des Spezialisierers:
|
|
|
|
* Wenn ein Typ (`stTuple`, `stVector`, `stMatrix`) ausschließlich statisch bekannte Typen (idealerweise Skalare wie `Ordinal` oder `Float`) enthält, wird er als **Value-Type** behandelt.
|
|
* **Monomorphisierter Pfad:** Der Spezialisierer erzeugt für diese Strukturen einen dedizierten Code-Pfad, der statt mit langsamen Objekt-Arrays mit flachen, gepackten Speicherblöcken arbeitet.
|
|
* **Kein implizites Casting:** Um die Inferenz stabil zu halten, findet keine automatische Umwandlung statt (z. B. wird ein `Ordinal` nicht automatisch zu `Float`, um einen Vektor zu erzwingen).
|
|
|
|
### 2.3 Unification (Vereinheitlichung der Konzepte)
|
|
|
|
Das Tupel-Konzept ersetzt mehrere bisherige Mechanismen:
|
|
|
|
* **Argument- & Parameterlisten:** Funktionsaufrufe werden semantisch als Übergabe eines Tupels behandelt. Dies ermöglicht hocheffiziente Registerübergabe.
|
|
* **Records:** Ein Record ist semantisch nur ein "Tagged Tuple". Die Daten liegen als Tupel vor, ein Keyword-Mapping sorgt lediglich für den namensbasierten Zugriff.
|
|
* **Multiple Returns:** Funktionen können nativ Tupel zurückgeben, was ohne zusätzliches Heap-Investment verarbeitet werden kann.
|
|
|
|
---
|
|
|
|
## 3. Skript-Beispiele und Inferenz
|
|
|
|
Die Syntax für alle Tupel-basierten Strukturen ist einheitlich `[...]`.
|
|
|
|
### A. Heterogene Strukturen (Tupel)
|
|
|
|
```script
|
|
(def tpl [1 3.14 "text"])
|
|
; Typ-Inferenz: stTuple<stOrdinal, stFloat, stText>
|
|
; Spezialisierung: Gepackter Record (Offset 0: Int64, Offset 8: Double, Offset 16: Ptr)
|
|
|
|
(get tpl 1) ; -> 3.14 (Der Compiler weiß statisch: Index 1 ist stFloat)
|
|
|
|
```
|
|
|
|
### B. Homogene Strukturen (Vektoren)
|
|
|
|
```script
|
|
(def v [10 20 30])
|
|
; Typ-Inferenz: stVector<stOrdinal, 3>
|
|
; Spezialisierung: Flaches Array von 3x Int64 (unboxed, SIMD-optimierbar)
|
|
|
|
(def i 2)
|
|
(get v i) ; -> 30 (Typsicher, da alle Elemente stOrdinal sind)
|
|
|
|
```
|
|
|
|
### C. Multidimensionale Strukturen (Matrizen)
|
|
|
|
Die Matrix-Invariante erfordert exakt gleiche Formen der Unterelemente.
|
|
|
|
```script
|
|
; 2D Matrix
|
|
(def mat2d [[1 2] [3 4]])
|
|
; Inferenz: stMatrix<stOrdinal, [2, 2]> (Rechteckig -> Optimierung aktiv)
|
|
|
|
; 3D Matrix
|
|
(def mat3d [[[1 2] [3 4]] [[5 6] [7 8]]])
|
|
; Inferenz: stMatrix<stOrdinal, [2, 2, 2]> (Linearisierter Speicherblock)
|
|
|
|
; Degradiertes Tupel (Shape-Mismatch)
|
|
(def mixed [[1 2] [3 4 5]])
|
|
; Inferenz: stVector<stTuple>
|
|
; Keine Matrix-Optimierung möglich, da Unter-Tupel Längen 2 und 3 haben.
|
|
|
|
```
|
|
|
|
### D. Records als Tupel-Sicht
|
|
|
|
```script
|
|
(def rec {:x 1, :y 0.3})
|
|
; Physisch: stTuple<stOrdinal, stFloat>
|
|
; Logisch: Record-Mapping {:x -> 0, :y -> 1}
|
|
|
|
```
|
|
|
|
---
|
|
|
|
## 4. Nächste Schritte
|
|
|
|
1. **`Myc.Ast.Types.pas`**:
|
|
* Erweitern von `TStaticTypeKind` und `IStaticType`.
|
|
* Implementierung von `TTupleType`, `TVectorType` und `TMatrixType`.
|
|
* Implementierung der rekursiven `IsScalarPure`-Prüfung.
|
|
(erledigt)
|
|
|
|
2. **`Myc.Ast.Compiler.TypeChecker.pas`**:
|
|
* Implementierung der Promotion-Kaskade (`stTuple` -> `stVector` -> `stMatrix`).
|
|
* Validierung der "Rechteckigkeit" bei geschachtelten Literalen.
|
|
|
|
|
|
3. **`Myc.Ast.Nodes.pas`**:
|
|
* Konsolidierung von `IArgumentList`, `IParameterList` etc. zu einer allgemeinen Tupel-Repräsentation.
|
|
|
|
|