MycLib/Doc/Tupel 1.md

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)

(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)

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

; 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

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

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.

---

Soll ich nun mit der Implementierung der Typ-Erweiterungen in Myc.Ast.Types.pas beginnen?