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