Warum funktionieren visuelle Programmiertools nicht direkt mit dem AST?

Ich habe mehrere Open-Source-Tools für die visuelle Programmierung wie Blockly und Freunde sowie andere bei Github gehostete Projekte gefunden, konnte jedoch keine finden, mit denen direkt gearbeitet werden kann der abstrakte Syntaxbaum.

Warum ist das so?

I „m Als ich herausfand, dass jeder Compiler eine Phase im Kompilierungsprozess hat, in der er den Quellcode in einen AST analysiert, war mir klar, dass einige visuelle Programmiertools dies nutzen könnten, um dem Programmierer Möglichkeiten zum Bearbeiten des zu geben AST direkt auf visuelle Weise und auch, um den Roundtrip von der Quelle zum Knotengraphen und dann bei Bedarf wieder zurück zur Quelle durchzuführen.

Zum Beispiel könnte man das von der JavaScript AST Visualizer zu einem tatsächlichen visuellen Programmierwerkzeug von JavaSript gibt es keinen allzu großen Unterschied.

Also , was fehlt mir?

Kommentare

  • ASTs sind sehr ausführlich und für die Programmierung nicht sehr praktisch. Sie wurden für Compiler und nicht für Programmierer entwickelt.
  • en.wikipedia.org/wiki/Structure_editor
  • Was tun? Sie meinen mit “ direkt mit dem abstrakten Syntaxbaum arbeiten „? Wahrscheinlich bearbeiten alle blockbasierten Tools wie Blockly den AST: Sie stellen Kanten durch Verschachteln (oder Stapeln, wenn Sie dies lieber so sehen möchten) dar, und der Benutzer kann den Baum durch Ziehen und Ablegen bearbeiten.
  • Es ‚ ist eine großartige Frage, die viele von uns, die Compiler mögen, hatten. Ich denke, die kurze Antwort lautet: Wenn Sie dies tun und benutzerfreundlich gestalten könnten, würden die Leute es verwenden. Das einzige Problem ist, dass ‚ ein großes “ ist, wenn „.
  • Haben Sie sich Lisp angesehen? “ [Es ‚ ist] nicht so sehr, dass Lisp eine seltsame Syntax hat, als dass Lisp keine Syntax hat. Sie schreiben Programme in die Analysebäume, die im Compiler generiert werden, wenn andere Sprachen analysiert werden. Diese Analysebäume sind jedoch für Ihre Programme vollständig zugänglich. Sie können Programme schreiben, die sie bearbeiten. “

Antwort

Viele dieser Tools arbeiten direkt mit dem abstrakten Syntaxbaum (oder besser gesagt einem direkten Eins-zu-Text) -eine Visualisierung davon). Dazu gehören Blockly, das Sie gesehen haben, und die anderen blockbasierten Sprachen und Editoren, die es mögen ( Scratch , Bleistiftcode / Droplet , Snap! , GP , Tiled Grace usw.

Diese Systeme funktionieren nicht zeigen eine traditionelle Darstellung von Scheitelpunkt- und Kantengraphen aus Gründen, die an anderer Stelle erläutert wurden (Raum und auch Interaktionsschwierigkeiten), aber sie repräsentieren direkt einen Baum. Ein Knoten oder Block ist ein Kind eines anderen, wenn er sich direkt physisch innerhalb des übergeordneten Knotens befindet.


Ich habe eines dieser Systeme erstellt ( Tiled Grace , Papier , Papier ). Ich kann Ihnen versichern, dass es sehr direkt mit dem AST funktioniert: Was Sie auf dem Bildschirm sehen, ist eine genaue Darstellung des Syntaxbaums als verschachtelte DOM-Elemente (also ein Baum!).

Screenshot des verschachtelten gekachelten Grace-Codes

Dies ist der AST eines Codes. Die Wurzel ist ein Methodenaufrufknoten „for … do“. Dieser Knoten hat einige untergeordnete Knoten, beginnend mit „_ .. _“, der selbst zwei untergeordnete Knoten hat, einen „1“ -Knoten und einen „10“ -Knoten. Was auf dem Bildschirm angezeigt wird, ist genau das, was das Compiler-Backend mitten im Prozess ausspuckt – so funktioniert das System im Grunde.

Wenn Sie möchten, können Sie es sich als Standardbaumlayout vorstellen Die Kanten zeigen aus dem Bildschirm in Ihre Richtung (und werden durch den Block vor ihnen verdeckt), aber das Verschachteln ist eine ebenso gültige Methode zum Anzeigen eines Baums wie ein Scheitelpunktdiagramm.

Es wird auch „funktionieren“ Der Roundtrip von der Quelle zum Knotendiagramm und dann bei Bedarf wieder zurück zur Quelle. Sie können dies sogar sehen, wenn Sie unten auf „Codeansicht“ klicken. Wenn Sie den Text ändern, wird er erneut angezeigt analysiert und der resultierende Baum gerendert, damit Sie ihn erneut bearbeiten können. Wenn Sie die Blöcke ändern, geschieht dasselbe mit der Quelle.


Der Bleistiftcode macht an dieser Stelle im Wesentlichen dasselbe mit: eine bessere Schnittstelle . Die verwendeten Blöcke sind eine grafische Ansicht des CoffeeScript AST.Dies gilt auch für die anderen block- oder kachelbasierten Systeme im Großen und Ganzen, obwohl einige von ihnen den Verschachtelungsaspekt in der visuellen Darstellung nicht ganz so deutlich machen und viele keine tatsächliche Textsprache hinter sich haben. Syntaxbaum „kann ein bisschen illusorisch sein, aber das Prinzip ist da.


Was Ihnen also fehlt, ist, dass diese Systeme wirklich direkt mit dem arbeiten abstrakter Syntaxbaum. Was Sie sehen und bearbeiten, ist ein platzsparendes Rendern eines Baums, in vielen Fällen buchstäblich der AST, den ein Compiler oder Parser erzeugt.

Antwort

Mindestens zwei Gründe:

  1. Da der Quellcode eine viel präzisere Darstellung ist. Erstellen eines AST als Diagramm würde viel mehr visuellen Platz beanspruchen.

    Programmierer schätzen es, so viel Kontext wie möglich zu haben – dh so viel Code gleichzeitig auf dem Bildschirm zu haben. Der Kontext hilft ihnen, besser zu verwalten Komplexität. (Das ist ein Grund, warum viele Progr Ammer verwenden diese verrückten kleinen Schriftarten und riesigen 30-Zoll-Bildschirme.)

    Wenn wir versuchen würden, den AST als Grafik oder Baum anzuzeigen, wäre die Menge an Code, die Sie auf einen einzelnen Bildschirm passen könnten, viel geringer als wenn es als Quellcode dargestellt wird. Dies ist ein großer Verlust für die Entwicklerproduktivität.

  2. ASTs sind für die Compilerprogrammierung gedacht und nicht für Programmierer leicht verständlich. Wenn Sie eine vorhandene AST-Darstellung übernehmen und visuell anzeigen würden, wäre es für Entwickler wahrscheinlich schwieriger zu verstehen, da ASTs für Entwickler nicht einfach zu erlernen sind.

    Im Gegensatz dazu ist Quellcode normalerweise ist so konzipiert, dass es für Entwickler lesbar / verständlich ist. Dies ist normalerweise ein kritisches Entwurfskriterium für den Quellcode, nicht jedoch für ASTs. ASTs müssen nur von den Compiler-Autoren verstanden werden, nicht von alltäglichen Entwicklern.

    Und in jedem Fall wäre die AST-Sprache eine zweite Sprache, die Entwickler zusätzlich zur Ausgangssprache lernen müssen. Kein Gewinn.

Siehe auch https://softwareengineering.stackexchange.com/q/119463/34181 für einige zusätzliche mögliche Gründe.

Kommentare

  • “ Im Gegensatz dazu ist der Quellcode für Entwickler lesbar / verständlich. “ – Gegenbeispiel: die meisten Esolangs, Perl, Lisp
  • “ Weil Der Quellcode ist eine viel präzisere Darstellung. „; “ Die AST-Sprache wäre eine zweite Sprache, die Entwickler zusätzlich zur Ausgangssprache lernen müssen. “ – dies sind Argumente gegen alle visuellen PLs, hilft aber nicht, die Unterscheidung zu erklären, um die es im OP geht.
  • “ (Das ‚ ist ein Grund, warum viele Programmierer diese verrückten kleinen Schriftarten und riesigen 30 “ Bildschirme verwenden.) “ – if Sie benötigen einen großen Bildschirm, um genügend Kontext anzuzeigen. Vielleicht ‚ sind Spaghetti-Codierer? 😉
  • @Raphael Vielleicht, aber ‚ ist weniger Aufwand, um Geld darauf zu werfen als Refactoring!
  • @JanDvorak, .. .LISP ist ein Gegenbeispiel, weil der AST die Sprache ist – was ihm seine Ausdruckskraft verleiht; Das Schreiben von LISP-Code, der Ihren anderen LISP-Code neu kompiliert, ist so einfach wie das Schreiben von Code, der Standard-LISP-Datenstrukturen ändert … genau das, in das LISP-Code geschrieben ist . Es gibt ‚ einen Grund, warum ‚ über ein halbes Jahrhundert gedauert hat – die Familie ‚ s Design ist ungewöhnlich ausdrucksstark. Die asynchronen Erweiterungen von Go mussten tief in die Sprache und die Laufzeit eingearbeitet werden. Für Clojure ist ‚ nur eine Bibliothek. Siehe auch: Die Durchschnittswerte schlagen .

Antwort

Der typische AST von Compilern ist ziemlich komplex und ausführlich. Die gerichtete Graphendarstellung würde schnell ziemlich schwer zu verfolgen sein. Es gibt jedoch zwei große Bereiche von CS, in denen ASTs verwendet werden.

  1. Lisp-Sprachen werden tatsächlich als AST geschrieben. Der Programmquellcode wird als Listen geschrieben und direkt vom Compiler und / oder Interpreter verwendet (abhängig davon, welche Variante verwendet wird).
  2. Modellierungssprachen, z. UML und viele visuell domänenspezifische Sprachen verwenden grafische Notationen, bei denen es sich um effektive abstrakte Syntaxgraphen (ASG) auf einer höheren Abstraktionsebene als die typische Allzwecksprache AST handelt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.