Znalazłem kilka narzędzi do programowania wizualnego typu open source, takich jak Blockly i przyjaciele, oraz inne projekty hostowane na Github, ale nie mogłem znaleźć żadnego, który działałby bezpośrednio z abstrakcyjne drzewo składni.
Dlaczego tak jest?
I „m pytając, ponieważ kiedy odkryłem, że każdy kompilator ma fazę w procesie kompilacji, w której analizuje kod źródłowy do AST, było dla mnie oczywiste, że niektóre wizualne narzędzia programistyczne mogą to wykorzystać, aby dać programiście możliwość edycji AST bezpośrednio w sposób wizualny, a także aby wykonać podróż w obie strony od źródła do grafu węzłów, a następnie z powrotem do źródła w razie potrzeby.
Na przykład można by pomyśleć, że z JavaScript AST Visualizer do rzeczywistego wizualnego narzędzia programowania JavaSript nie ma dużej różnicy.
Więc czego mi brakuje?
Komentarze
- AST są bardzo rozwlekłe i niezbyt wygodne w programowaniu. Zostały zaprojektowane dla kompilatorów, a nie programistów.
- en.wikipedia.org/wiki/Structure_editor
- Co zrobić masz na myśli, że ” pracujesz bezpośrednio z abstrakcyjnym drzewem składni „? Prawdopodobnie wszystkie narzędzia oparte na blokach, takie jak Blockly, edytują AST: reprezentują krawędzie przez zagnieżdżanie (lub układanie w stos, jeśli wolisz to widzieć w ten sposób), a użytkownik może edytować drzewo przez (powiedzmy) przeciąganie i upuszczanie.
- To ' to świetne pytanie, które zadawało wielu z nas, lubiących kompilatory. Myślę, że krótka odpowiedź jest taka, że gdybyś mógł to zrobić i uczynić go przyjaznym dla użytkownika, ludzie by go używali. Jedynym problemem jest to, że ' to duży ” if „.
- Czy znasz już Lisp ? ” [It ' s] nie tak bardzo, że Lisp ma dziwną składnię, ponieważ Lisp nie ma składni. Piszesz programy w drzewach analizy, które są generowane w kompilatorze, gdy analizowane są inne języki. Ale te drzewa parsowania są w pełni dostępne dla twoich programów. Możesz pisać programy, które nimi manipulują. ”
Odpowiedź
Wiele z tych narzędzi do współpracuje bezpośrednio z abstrakcyjnym drzewem składni (a raczej bezpośrednim -jedna wizualizacja tego). Obejmuje to Blockly, które już widzieliście, oraz inne języki oparte na blokach i podobne do niego edytory ( Scratch , Pencil Code / Droplet , Snap! , GP , Tiled Grace i tak dalej).
Te systemy nie pokazują tradycyjną reprezentację grafową wierzchołków i krawędzi, z powodów wyjaśnionych gdzie indziej (przestrzeń, a także trudność interakcji), ale bezpośrednio reprezentują one drzewo. Jeden węzeł lub blok jest dzieckiem innego, jeśli znajduje się bezpośrednio, fizycznie wewnątrz rodzica.
Zbudowałem jeden z tych systemów ( Tiled Grace , papier , papier ). Mogę Cię zapewnić, że bardzo dużo działa bezpośrednio z AST: to, co widzisz na ekranie, jest dokładną reprezentacją drzewa składni, jako zagnieżdżonych elementów DOM (a więc drzewa!).
To jest AST jakiegoś kodu. Katalog główny jest węzłem wywołania metody „for … do”. Ten węzeł ma kilka dzieci, zaczynając od „_ .. _”, który sam ma dwoje dzieci, węzeł „1” i węzeł „10”. To, co pojawia się na ekranie, jest dokładnie tym, co backend kompilatora wypluwa w środku procesu – tak właśnie działa system.
Jeśli chcesz, możesz o tym myśleć jak o standardowym układzie drzewa z krawędziami skierowanymi na zewnątrz ekranu do Ciebie (i zasłoniętymi przez blok przed nimi), ale zagnieżdżanie jest równie ważnym sposobem pokazania drzewa jak diagram wierzchołków.
podróż w obie strony od źródła do wykresu węzła, a następnie z powrotem do źródła w razie potrzeby ”. W rzeczywistości możesz to zobaczyć, klikając„ Widok kodu ”u dołu. Jeśli zmodyfikujesz tekst, zostanie ponownie przeanalizowany i wynikowe drzewo renderowane, abyś mógł ponownie edytować, a jeśli zmodyfikujesz bloki, to samo stanie się ze źródłem.
Kod ołówka robi zasadniczo to samo z, w tym momencie, lepszy interfejs . Używane przez niego bloki to graficzny widok CoffeeScript AST.Podobnie jest z innymi systemami opartymi na blokach lub kafelkach, ogólnie rzecz biorąc, chociaż niektóre z nich nie przedstawiają aspektu zagnieżdżania tak wyraźnie w wizualnej reprezentacji, a wiele z nich nie ma za sobą rzeczywistego języka tekstowego, więc drzewo składni ”może być trochę iluzoryczne, ale zasada istnieje.
W takim razie brakuje ci tego, że te systemy naprawdę pracują bezpośrednio z abstrakcyjne drzewo składni. To, co widzisz i manipulujesz, to wydajne przestrzennie renderowanie drzewa, w wielu przypadkach dosłownie AST, który tworzy kompilator lub parser.
Odpowiedź
Co najmniej z dwóch powodów:
-
Ponieważ kod źródłowy jest dużo bardziej zwięzłą reprezentacją. Przedstawienie AST jako wykresu zajmowałby dużo więcej miejsca wizualnego.
Programiści cenią sobie możliwie jak najwięcej kontekstu – tj. posiadanie jak największej ilości kodu w tym samym czasie na ekranie. Kontekst pomaga im lepiej zarządzać złożoność (to jeden z powodów, dla których wiele osób progr amatorzy używają tych zwariowanych małych czcionek i ogromnych 30-calowych ekranów.)
Gdybyśmy próbowali wyświetlić AST jako wykres lub drzewo, ilość kodu, który można by zmieścić na jednym ekranie, byłaby znacznie mniejsza niż gdy jest reprezentowany jako kod źródłowy. To ogromna strata dla produktywności programistów.
-
Programy AST są przeznaczone do programowania kompilatorów, a nie do łatwego zrozumienia przez programistów. Gdybyś wziął istniejącą reprezentację AST i pokazał ją wizualnie, prawdopodobnie byłoby to trudniejsze do zrozumienia dla programistów, ponieważ AST nie zostały zaprojektowane tak, aby były łatwe do nauki dla programistów.
W przeciwieństwie do tego, kod źródłowy zwykle jest zaprojektowany tak, aby był czytelny / zrozumiały dla programistów; jest to zwykle krytyczne kryterium projektowe dla kodu źródłowego, ale nie dla AST. AST muszą być zrozumiane tylko przez autorów kompilatorów, a nie przez zwykłych programistów.
W każdym razie język AST byłby drugim językiem, którego musieliby się nauczyć programiści, oprócz języka źródłowego. To nie wygrana.
Zobacz także https://softwareengineering.stackexchange.com/q/119463/34181 , aby uzyskać dodatkowe potencjalne przyczyny.
Komentarze
- ” W przeciwieństwie do tego kod źródłowy został zaprojektowany tak, aby był czytelny / zrozumiały dla programistów ” – kontrprzykład: większość esolangów, Perl, Lisp
- ” Becaus Kod źródłowy jest dużo bardziej zwięzłą reprezentacją. „; ” język AST byłby drugim językiem, którego musieliby się nauczyć programiści, oprócz języka źródłowego ” – to są argumenty przeciwko wszystkie wizualne PL, ale nie pomaga wyjaśnić różnicy, o którą chodzi w PO.
- ” (To ' to jeden z powodów, dla których wielu programistów używa tych zwariowanych małych czcionek i ogromnych 30 ” ekranów.) ” – jeśli potrzebujesz dużego ekranu, aby wyświetlić wystarczający kontekst, może ' używasz jeszcze kodu spaghetti? 😉
- @Raphael Być może, ale ' to mniej wysiłku niż refaktoryzacja!
- @JanDvorak, .. .LISP jest kontrprzykładem, ponieważ AST jest językiem – i dzięki temu ma moc ekspresji; pisanie kodu LISP, który rekompiluje twój inny kod LISP jest tak proste, jak napisanie kodu, który modyfikuje standardowe struktury danych LISP … które są dokładnie tym, w czym jest napisany kod LISP . ' jest powód, dla którego ' przetrwało ponad pół wieku – rodzina ' projekt jest niezwykle ekspresyjny. Go musiało mieć swoje rozszerzenia asynchroniczne głęboko zintegrowane z językiem i środowiskiem wykonawczym; dla Clojure jest to tylko biblioteka '. Zobacz też: Pokonywanie średnich .
Odpowiedź
Typowe kompilatory AST są dość złożone i rozwlekłe. Ukierunkowana reprezentacja graficzna szybko stałaby się trudna do śledzenia. Ale są dwa duże obszary CS, w których używane są AST.
- Języki Lisp są tak naprawdę napisane jako AST. Kod źródłowy programu jest zapisywany jako listy i bezpośrednio używany przez kompilator i / lub interpreter (w zależności od tego, który wariant jest używany).
- Języki modelowania, np. UML i wiele języków specyficznych dla dziedzin wizualnych używa notacji graficznych, które są efektywnymi abstrakcyjnymi grafami składniowymi (ASG) na wyższym poziomie abstrakcji niż typowy język ogólnego przeznaczenia AST.