# Projektplan: Hybride Monomorphisierung

* **Datum:** 30.10.2025
* **Version:** 1.0

## 1. Motivation

Das aktuelle Typsystem (`Myc.Ast.Types`) ist mächtig, aber die Inferenz für Lambda-Parameter endet bei `stUnknown`. Dies erzwingt Laufzeit-Typüberprüfungen im `TEvaluatorVisitor` und verkompliziert AOT/JIT-Kompilierung.

## 2. Ziel

Implementierung einer **hybriden Monomorphisierungsstrategie** zur Compile-Zeit (innerhalb des `TAstBinder`).

1.  **Statische Spezialisierung:** Alle Funktionsaufrufe, deren Callee *und* Argumenttypen zur Compile-Zeit statisch bekannt sind, werden spezialisiert. `stUnknown` wird für diese Pfade eliminiert.
2.  **Dynamischer Fallback:** Alle dynamischen Aufrufe (z.B. Higher-Order-Funktionen, deren Callee aus einer Variable stammt) nutzen weiterhin den bestehenden dynamischen Pfad (`vkMethod` mit `TDataValue`-Wrapper).
3.  **Optimierungs-Vorbereitung:** Der statisch spezialisierte AST (der "Entrypoint") dient als saubere Basis für optionale Optimierungen (z.B. LLVM-Codegen).

## 3. Ergebnis: Die Strategie

Die Implementierung erfordert eine Erweiterung des `TAstBinder`, um einen **Spezialisierungs-Cache** zu verwalten und bei Bedarf **rekursive Binding-Pässe** durchzuführen.

### Phase 1: Modifikation der Kern-Typen

1.  **`TBoundLambdaExpressionNode` (Generic):**
    * Muss seinen *originalen, ungebundenen* Body (`IAstNode`) behalten, um als Vorlage für das Re-Binding zu dienen.
    * Führt einen **Spezialisierungs-Cache** (z.B. `TDictionary<TSignatureHash, ISpecializedBody>`).
2.  **`ISpecializedBody` (Interface):**
    * Repräsentiert einen erfolgreich monomorphisierten Entrypoint.
    * `function GetBodyAst: IAstNode;`
    * `function GetScopeDescriptor: IScopeDescriptor;`
    * `function GetReturnType: IStaticType;`
3.  **`TBoundFunctionCallNode`:**
    * Benötigt ein neues Feld, um *entweder* den dynamischen Callee (wie bisher) *oder* den statischen `ISpecializedBody` (den Entrypoint) zu halten.

### Phase 2: Anpassung des `TAstBinder` (Trigger)

`TAstBinder.VisitFunctionCall` wird zur zentralen Weichenstellung:

1.  Binde alle Argumente und ermittle ihre statischen Typen (die `Aufrufsignatur`).
2.  Binde den `Callee`.
3.  **Fallunterscheidung:**
    * **Fall A (Dynamischer Aufruf):** Der `Callee` ist *nicht* als `TBoundLambdaExpressionNode` statisch bekannt (z.B. `(map (if flag f1 f2) ...)`).
        * **Aktion:** Der Aufruf wird als dynamisch belassen (Fallback). Es wird lediglich geprüft, ob der `Callee` den Typ `stMethod` hat. Es findet keine Spezialisierung statt.
    * **Fall B (Statischer Aufruf):** Der `Callee` ist ein `TBoundLambdaExpressionNode`.
        * **Aktion:** Trigger die Monomorphisierung.
        * Rufe `Callee.GetSpecialization(Aufrufsignatur)` auf.
        * Der `TBoundFunctionCallNode` wird modifiziert und verweist direkt auf das zurückgegebene `ISpecializedBody`.
        * Der `StaticType` des `TBoundFunctionCallNode` wird auf `ISpecializedBody.GetReturnType` gesetzt.

### Phase 3: Die Monomorphisierung (Der Re-Bind Pass)

Dies ist die Kernlogik (z.B. in `TBoundLambdaExpressionNode.GetSpecialization`):

1.  **Cache-Lookup:** Prüfe, ob für die `Aufrufsignatur` bereits ein `ISpecializedBody` im Cache existiert.
2.  **Cache-Miss (Re-Binding):**
    * Erzeuge einen neuen, temporären `IScopeDescriptor` für den Sub-Bind-Prozess.
    * **Populiere den Scope:** Definiere die Parameter-Namen (z.B. `[a b]`) in diesem Scope, aber verwende die *konkreten Typen* der `Aufrufsignatur` (z.B. `stFloat`, `stOrdinal`) anstelle von `stUnknown`.
    * **Rekursiver Binder:** Erzeuge einen neuen `TAstBinder` (oder rufe den aktuellen re-entrant auf), der den *originalen, ungebundenen Body* des Lambdas mit diesem spezialisierten Scope bindet.
    * **Fehlerbehandlung:** Schlägt dieser Sub-Bind-Prozess fehl (z.B. `ETypeException`, weil `a` (jetzt `stFloat`) mit einem `Text` addiert wird), ist der Aufruf ungültig -> **Compile-Fehler**.
    * **Erfolg:** Das Ergebnis ist der spezialisierte `IAstNode` (Body) und der `IScopeDescriptor`. Erzeuge ein `ISpecializedBody`-Objekt, speichere es im Cache und gib es zurück.

### Phase 4: Anpassung des `TEvaluatorVisitor` (Ausführung)

`TEvaluatorVisitor.VisitFunctionCall` muss nun zwei Arten von Calls behandeln:

1.  **Dynamischer Call:** `Callee` ist `vkMethod`. (Wie bisher: `(calleeValue.AsMethod)(argValues)`).
2.  **Statischer/Monomorphisierter Call:** `Callee` ist ein `ISpecializedBody`.
    * Erzeuge den `IExecutionScope` (via `ISpecializedBody.GetScopeDescriptor`).
    * Populiere den Scope mit den (bereits evaluierten) `argValues`.
    * Führe den `ISpecializedBody.GetBodyAst` direkt mit `Accept(Self)` aus. (TCO muss hier ebenfalls beachtet werden).

### Phase 5: LLVM-Optimierung (Optional)

Der in Phase 3 erzeugte `ISpecializedBody` ist der "corner case" für die Optimierung:

* Wenn ein `ISpecializedBody` erfolgreich erstellt wurde *und* dieser AST-Body die "harten" Kriterien erfüllt (keine dynamischen Internals), wird er als **Kandidat für LLVM-AOT/JIT** markiert.
* Ein LLVM-Backend kann diese Kandidaten aufnehmen, LLVM-IR generieren und den `ISpecializedBody` im Cache durch einen nativen Funktionspointer (den FFI-Entrypoint) ersetzen.

---

## 4. TODOs

* [ ] `TBoundLambdaExpressionNode` erweitern, um den originalen Body und den Spezialisierungs-Cache zu halten.
* [ ] `ISpecializedBody` (oder äquivalente Struktur) definieren.
* [ ] `TAstBinder.VisitFunctionCall` um die Weichenstellung (Fall A/B) erweitern.
* [ ] Den re-entranten Monomorphisierungs-Pass (Phase 3) implementieren.
* [ ] `TEvaluatorVisitor.VisitFunctionCall` für die Ausführung von `ISpecializedBody` anpassen.
* [ ] Typsystem (`TTypeRules`) auf Robustheit für die neuen, strikten Prüfungen im Sub-Bind-Pass testen.