RustAst/docs/ListNodes.md

Projektplan: Refactoring auf First-Class List Nodes

Datum: 29.11.2025 16:43

1. Motivation

Aktuell werden Listen von Elementen im AST (z. B. Parameter in Lambda, Argumente in Call, Felder in RecordLiteral) als native Arrays (TArray<T>) innerhalb des Eltern-Knotens gespeichert. Dies führt zu signifikanten Problemen bei der Entwicklung des Projectional Editors:

1. Fehlende Adressierbarkeit: Eine Liste als TArray hat keine Identität (IAstIdentity) und keine Position. Sie kann im Editor nicht als Ganzes selektiert, fokussiert oder hervorgehoben werden.
2. Das "Leere-Liste"-Problem: Wenn eine Liste leer ist, gibt es keinen visuellen Anker (wie einen Platzhalter zwischen Klammern), den der Benutzer anklicken kann, um das erste Element einzufügen.
3. Inkonsistente UI-Logik: Jeder Handler (LambdaHandler, CallHandler, etc.) muss derzeit selbstständig Logik für Klammern (), Trennzeichen , und Layout implementieren. Dies führt zu Code-Duplizierung.
4. Komplexe Manipulation: Operationen wie "Verschiebe Argument 2 an Position 1" oder "Lösche alle Parameter" sind schwierig umzusetzen, da die Logik fest im Eltern-Knoten verdrahtet ist und nicht an einen generischen Listen-Handler delegiert werden kann.
5. Record-Felder: Aktuell sind Key-Value-Paare (TRecordFieldLiteral) reine Records, keine AST-Nodes. Sie können daher nicht einzeln selektiert oder per Drag & Drop verschoben werden.

Um einen robusten, wartbaren Editor zu gewährleisten, muss das Prinzip "Alles, was sichtbar und manipulierbar ist, muss ein AST-Knoten sein" konsequent angewendet werden.

2. Ziel

Umbau der AST-Struktur und der Editor-Handler, um Listen und Record-Felder als eigenständige Knoten zu etablieren.

Kernaufgaben:

1. AST-Erweiterung (Myc.Ast.Nodes):

   • Einführung eines generischen Interfaces INodeList<T: IAstNode>.
   • Einführung spezifischer Listen-Typen zur Wahrung der Typsicherheit: IParameterList, IArgumentList, IRecordFieldList.
   • Einführung von IRecordFieldNode als Wrapper für Key-Value-Paare.
   • Erweiterung des TAstNodeKind Enums.

2. Anpassung der Factories & Visitor (Myc.Ast & Myc.Ast.Visitor):

   • Update der Factory-Methoden (z.B. TAst.LambdaExpr), um Listen-Nodes statt Arrays zu akzeptieren.
   • Erweiterung des IAstVisitor um Methoden für die neuen Knotentypen.

3. Generischer UI-Handler (Myc.Fmx.AstEditor.Handlers):

   • Implementierung von TNodeListHandler<T>, der das Rendering von Listen (Start-Zeichen, Trennzeichen, End-Zeichen, Layout) zentralisiert.
   • Implementierung der IEditableNodeHandler-Logik im Listen-Handler (Hinzufügen neuer Elemente).

4. Refactoring existierender Handler:

   • Vereinfachung von TLambdaExpressionNodeHandler, TFunctionCallNodeHandler und TRecordLiteralNodeHandler durch Delegation an den neuen TNodeListHandler.

3. Ergebnis

• Architektonische Konsistenz: Der AST spiegelt die logische Struktur der Sprache und die visuelle Struktur des Editors 1:1 wider.
• Reduzierte Komplexität: UI-Logik für Listen existiert nur noch einmal zentral im TNodeListHandler.
• Erweiterte Funktionalität: Listen können nun selektiert, kopiert und geleert werden. Leere Listen sind durch ihre Klammern als Drop-Target für neue Elemente nutzbar.
• Typsicherheit: Trotz generischer Implementierung im Editor bleibt die semantische Unterscheidung (Parameter vs. Argumente) im AST und Compiler erhalten.

4. Nächster Schritt

Implementierung der Änderungen in Myc.Ast.Nodes (Definition der Interfaces INodeList, IParameterList, IArgumentList, IRecordFieldList, IRecordFieldNode) und Anpassung der TAstNodeKind Enumeration.