Našel jsem několik vizuálních programovacích nástrojů open source, jako je Blockly a přátelé, a další projekty hostované na Githubu, ale nemohl jsem najít žádné, které by fungovaly přímo s abstraktní strom syntaxe.
Proč je to tak?
Jsem ptát se, protože jakmile jsem zjistil, že každý kompilátor má fázi procesu kompilace, kde analyzuje zdrojový kód na AST, bylo mi zřejmé, že některé vizuální programovací nástroje by toho mohly využít a dát programátorovi způsoby, jak upravit AST přímo vizuálním způsobem, a také provést zpáteční cestu ze zdroje do grafu uzlů a poté v případě potřeby zpět zpět ke zdroji.
Například by si někdo mohl myslet, že z JavaScript AST Visualizer ke skutečnému vizuálnímu programovacímu nástroji JavaSript není příliš velký rozdíl.
Takže , co mi chybí?
Komentáře
- AST jsou velmi podrobné a nejsou příliš vhodné pro programování. Byly navrženy pro překladače, nikoli pro programátory.
- en.wikipedia.org/wiki/Structure_editor
- Co dělat máte na mysli “ pracovat přímo s abstraktním stromem syntaxe „? Pravděpodobně všechny blokové nástroje jako Blockly upravují AST: představují hrany vnořením (nebo stohováním, pokud to tak chcete vidět) a uživatel může strom upravit (řekněme) přetažením.
- Je to ‚ skvělá otázka pro mnoho z nás, kteří mají rádi kompilátory. Myslím, že krátká odpověď je, že pokud to dokážete a učiníte to uživatelsky přívětivým, lidé by to použili. Jediným problémem je, že ‚ je velký “ pokud „.
- Podívali jste se na Lisp ? “ [It ‚ s] ne tolik, aby měl Lisp zvláštní syntaxi, protože Lisp žádnou syntaxi nemá. Programy píšete do analyzovaných stromů, které se generují v kompilátoru při analýze jiných jazyků. Ale tyto parsovací stromy jsou plně přístupné vašim programům. Můžete psát programy, které s nimi manipulují. “
Odpovědět
Mnoho z těchto nástrojů pracuje přímo s abstraktním stromem syntaxe (nebo spíše přímým – jedna jeho vizualizace). To zahrnuje Blockly, kterou jste již viděli, a další blokové jazyky a editory, které se jí líbí ( Scratch , Pencil Code / Droplet , Snap! , GP , Kachlová milost atd.).
Tyto systémy nejsou ukazují tradiční graf grafu vrchol-hrana, z důvodů vysvětlených jinde (prostor a obtížnost interakce), ale přímo představují strom. Jeden uzel nebo blok je potomkem jiného, pokud je přímo, fyzicky uvnitř rodiče.
Jeden z těchto systémů jsem vytvořil ( Kachlová milost , papír , papír ). Mohu vás ujistit, že pracuje přímo s AST: to, co vidíte na obrazovce, je přesná reprezentace syntaxového stromu jako vnořených prvků DOM (tedy strom!).
Toto je AST nějakého kódu. Kořenový adresář je uzel volání metody „for … do“. Tento uzel má několik podřízených, počínaje řetězcem „_ .. _“, který sám má dvě podřízené jednotky, uzel „1“ a uzel „10“. To, co se objeví na obrazovce, je přesně to, co backend kompilátoru vyplivne uprostřed procesu – to je zásadní způsob fungování systému.
Pokud chcete, můžete si to představit jako standardní rozložení stromu s hranami směřujícími z obrazovky směrem k vám (a zakryté blokem před nimi), ale vnoření je stejně platný způsob, jak zobrazit strom jako vrcholový diagram.
Bude také „dělat zpáteční cesta ze zdroje do grafu uzlů a poté zpět na zdroj v případě potřeby „. Ve skutečnosti to vidíte, když kliknete na„ Zobrazení kódu „dole. Pokud upravíte text, bude„ analyzován a výsledný strom vykreslen, abyste jej mohli znovu upravovat, a pokud upravíte bloky, stane se to samé se zdrojem.
Tužkový kód v zásadě dělá to samé, lepší rozhraní . Bloky, které používá, jsou grafickým zobrazením CoffeeScript AST.Stejně tak i ostatní systémy založené na blocích nebo dlaždicích, obecně, i když některé z nich nedělají hnízdní aspekt ve vizuální reprezentaci tak jasný, a mnoho z nich nemá za sebou skutečný textový jazyk, takže strom syntaxe „může být trochu iluzorní, ale princip tu je.
To, co vám chybí, tedy je, že tyto systémy skutečně pracují přímo s abstraktní syntaxový strom. To, co vidíte a manipulujete, je prostorově efektivní vykreslení stromu, v mnoha případech doslova AST, který kompilátor nebo analyzátor produkuje.
Odpovědět
Alespoň dva důvody:
-
Protože zdrojový kód je mnohem výstižnější vyjádření. Rozložení AST jako grafu zabralo by mnohem více vizuálních nemovitostí.
Cena programátorů s co největším počtem kontextů – tj. mít na obrazovce najednou tolik kódu najednou. Kontext jim pomáhá lépe spravovat (To je jeden z důvodů, proč mnoho programů ammers používají tato šílená malá písma a obrovské 30 „obrazovky.)
Pokud bychom se pokusili zobrazit AST jako graf nebo strom, pak by množství kódu, které by se vešlo na jednu obrazovku, bylo mnohem menší než když je reprezentován jako zdrojový kód. To je obrovská ztráta pro produktivitu vývojářů.
-
AST jsou určena pro programování kompilátorů, nikoli pro snadné pochopení programátory. Pokud jste převzali existující reprezentaci AST a zobrazili ji vizuálně, bylo by to pro vývojáře pravděpodobně těžší pochopit, protože AST nebyly navrženy tak, aby se vývojářům snadno naučily.
Naproti tomu zdrojový kód obvykle je navrženo tak, aby jej vývojáři mohli číst / srozumit; to je obvykle kritické návrhové kritérium pro zdrojový kód, ale ne pro AST. AST musí pochopit pouze autoři překladačů, nikoli běžní vývojáři.
A v každém případě by byl jazyk AST druhým zdrojovým jazykem, který se vývojáři musí naučit. Žádná výhra.
Další potenciální důvody viz také https://softwareengineering.stackexchange.com/q/119463/34181 .
Komentáře
- “ Naproti tomu je zdrojový kód navržen tak, aby jej vývojáři mohli číst / srozumit “ – protiklad: většina esolangů, Perl, Lisp
- “ Becaus Zdrojový kód je mnohem výstižnější reprezentací. „; “ jazyk AST by byl druhým jazykem, který se vývojáři musí naučit, kromě zdrojového jazyka “ – to jsou argumenty proti všechny vizuální PL, ale nepomůže vysvětlit rozdíl, kterého se OP týká.
- “ (To ‚ jedním z důvodů, proč mnoho programátorů používá tato šílená malá písma a obrovské 30 “ obrazovky.) “ – pokud potřebujete velkou obrazovku, abyste si mohli prohlédnout dostatek kontextu, možná ‚ re spaghetti-coding? 😉
- @Raphael Možná, ale ‚ je menší úsilí vrhnout na to peníze než refaktorovat!
- @JanDvorak, .. .LISP je protipříklad, protože AST je jazyk – což mu dává jeho expresivní sílu; psaní kódu LISP, který překompiluje váš další kód LISP, je stejně snadné jako psaní kódu, který upravuje standardní datové struktury LISP … které jsou přesně to, v čem je napsán kód LISP . Existuje ‚ důvod, proč ‚ s trvalo déle než půl století – rodina ‚ design je neobvykle expresivní. Go musel mít svá asynchronní rozšíření zasunutá hluboko do jazyka a běhu; pro Clojure je to ‚ pouze knihovna. Viz také: Překonání průměrů .
Odpověď
Typický AST podle překladačů je poměrně složitý a podrobný. Řízené znázornění grafu by se rychle stalo docela obtížným. Existují však dvě velké oblasti CS, kde se používají AST.
- Lisp jazyky jsou ve skutečnosti psány jako AST. Zdrojový kód programu je psán jako seznamy a je přímo používán překladačem a / nebo tlumočníkem (v závislosti na použité variantě).
- Modelovací jazyky, např. UML a mnoho jazyků specifických pro vizuální doménu používají grafické notace, které jsou efektivní grafy abstraktní syntaxe (ASG) na vyšší úrovni abstrakce než typický obecný jazyk AST.