Einführung von N-dimensionalen Tupel-Strukturen und Typ-Unification #1

New Issue

2026-01-19T09:52:24+01:00

Brummel commented

2026-01-19 09:52:24 +01:00

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:

stTuple: Der Basisfall. Eine heterogene Sequenz fester Länge (z. B. [1 "Text"]). Jeder Slot hat seinen eigenen statischen Typ.
stVector: Ein Spezialfall des Tupels. Alle Elemente besitzen den identischen statischen Typ (Homogenität). Dies erlaubt den typsicheren Zugriff über variable Indizes.
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}

## 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:** - [x] **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: - [x] **`stTuple`**: Der Basisfall. Eine heterogene Sequenz fester Länge (z. B. `[1 "Text"]`). Jeder Slot hat seinen eigenen statischen Typ. - [x] **`stVector`**: Ein Spezialfall des Tupels. Alle Elemente besitzen den **identischen** statischen Typ (Homogenität). Dies erlaubt den typsicheren Zugriff über variable Indizes. - [x] **`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: - [x] **Argument- & Parameterlisten:** Funktionsaufrufe werden semantisch als Übergabe eines Tupels behandelt. Dies ermöglicht hocheffiziente Registerübergabe. - [x] **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. - [x] **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 `[...]`. - [x] 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) ``` - [x] 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) ``` - [x] 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. ``` - [x] D. Records als Tupel-Sicht ```script (def rec {:x 1, :y 0.3}) ; Physisch: stTuple<stOrdinal, stFloat> ; Logisch: Record-Mapping {:x -> 0 :y -> 1} ```

Brummel added this to the Aura project 2026-01-19 09:52:24 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/MycLib#1

Einführung von N-dimensionalen Tupel-Strukturen und Typ-Unification #1