Files
RustAst/docs/Visual Editor 1.md
Michael Schimmel 494bf554d2 Old Docs added
2026-02-20 10:09:22 +01:00

3.1 KiB

Projektplan: Myc Compiler & Visual Editor Integration

Datum: 28.11.2025 12:42

Motivation

Der Compiler-Kern wurde erfolgreich auf eine robuste, immutable Architektur umgestellt ("Green Tree / Red Tree"). Durch die Einführung von IAstIdentity und einem Logging-basierten Fehlersystem ("Fail-Safe") gehen Metadaten während der Transformationen (Binder, TypeChecker, Optimierung) nicht mehr verloren. Der nächste logische Schritt ist die Integration dieser Intelligenz in den visuellen Editor. Der Editor soll nicht nur dumme Blöcke darstellen, sondern Live-Feedback (Fehler, Typen) geben, indem er die stabilen Identitäten für den "Round-Trip" nutzt.

Ziel

Herstellung einer bidirektionalen Verbindung zwischen dem visuellen TAuraNode-Graphen und dem logischen IAstNode-Baum.

  1. Rekonstruktion: Der visuelle Baum erzeugt einen logischen AST (inkl. Mapping).
  2. Kompilierung: Der Compiler verarbeitet den AST und liefert Fehler/Typen referenziert auf IAstIdentity.
  3. Visualisierung: Der Editor projiziert diese Informationen zurück auf die entsprechenden UI-Knoten.

Ergebnis (Status Quo)

  • Compiler Core: Vollständig refaktoriert. Binder, TypeChecker, TCO und Specializer unterstützen ICompilerLog und nutzen "Poison Pills" (Unknown-Typen) statt Exceptions.
  • AST Architektur: IAstIdentity trennt erfolgreich Syntax-Daten von Semantik. Factories (TAst) erzwingen den Erhalt der Provenance (Herkunft) bei Transformationen.
  • Editor Basis: Myc.Fmx.AstEditor.Node wurde angepasst, um die neuen Factories zu nutzen. ReconstructAst funktioniert prinzipiell.

Nächster Schritt: Implementierung der Editor-Intelligenz

Die Umsetzung erfolgt in drei logischen Phasen:

Phase 1: Visuelle Feedback-Mechanismen (View)

Erweiterung von TAuraNode um die Fähigkeit, Status-Informationen darzustellen, ohne die Kernlogik zu überladen.

  • Implementierung von Adorners/Decorators für TAuraNode.
  • Visualisierung von Fehlern (z.B. roter Rahmen, Warnsymbol, Tooltip mit Fehlermeldung).
  • Visualisierung von Typ-Informationen (z.B. kleines Badge mit "Int64", "Series" etc.).
  • Methoden zum Setzen und Löschen dieser Zustände (SetErrorState, SetTypeInfo, ClearStatus).

Phase 2: Mapping-Infrastruktur (Glue Code)

Implementierung der externen Verknüpfung zwischen Logik und UI, um den AST "rein" zu halten.

  • Definition eines TAstMapping-Kontextes (enthält Dictionary<IAstIdentity, TAuraNode>).
  • Anpassung des Rekonstruktions-Prozesses: Während ReconstructAst läuft, muss die Verbindung zwischen der (wiederverwendeten oder neuen) Identity und dem TAuraNode im Mapping registriert werden.

Phase 3: Der Editor-Controller (Brain)

Erstellung einer neuen Unit Myc.Fmx.AstEditor.Controller, die den Workflow steuert.

  • Orchestrierung: Workspace -> AST -> Compiler -> UI-Update.
  • Verarbeitung des ICompilerLog: Iteration über Fehler, Lookup im Mapping, Update der UI-Nodes.
  • Verarbeitung des TypedAst: Extraktion von Typen für Mouse-Over oder permanente Anzeige.