Narzędzia do programowania wizualnego, dlaczego nie współpracują bezpośrednio z AST?

25

Znalazłem kilka narzędzi do programowania wizualnego typu open source, takich jak Blockly i przyjaciele oraz inne projekty hostowane w Github, ale nie mogłem znaleźć żadnego, który działałby bezpośrednio z abstrakcyjnym drzewem składni.

Dlaczego?

Pytam, 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 do programowania mogą to wykorzystać, aby dać programistom sposoby aby edytować AST bezpośrednio w sposób wizualny, a także w obie strony od źródła do wykresu węzła, a następnie w razie potrzeby z powrotem do źródła.

Można na przykład pomyśleć, że od JavaScript AST Visualizer do rzeczywistego wizualnego narzędzia do programowania JavaSript nie ma zbyt dużej różnicy.

Więc czego mi brakuje?

rraallvv
źródło
10
AST są bardzo szczegółowe i niezbyt wygodne w programowaniu. Zostały zaprojektowane dla kompilatorów, a nie programistów.
Yuval Filmus,
1
Co rozumiesz przez „pracę bezpośrednio z abstrakcyjnym drzewem składni”? Prawdopodobnie wszystkie narzędzia oparte na blokach, takie jak Blockly, edytują AST: reprezentują krawędzie poprzez zagnieżdżanie (lub układanie w stosy, jeśli wolisz widzieć to w ten sposób), a użytkownik może edytować drzewo, powiedzmy, przeciągając i upuszczając.
Michael Homer
To świetne pytanie, które wielu z nas lubi kompilatory. Myślę, że krótka odpowiedź jest taka, że ​​gdybyś mógł to zrobić i uczynić go przyjaznym dla użytkownika, ludzie by z niego skorzystali. Jedynym problemem jest to, że jest to duże „jeśli”.
Mehrdad
2
Zajrzałeś do Lisp ? „[Nie] jest tak bardzo, że Lisp ma dziwną składnię, ale to, że Lisp nie ma składni. Piszecie programy w drzewach analizy, które są generowane w kompilatorze podczas analizowania innych języków. Ale te drzewa analizy są w pełni dostępne dla waszych programów. Możesz pisać programy, które nimi manipulują ”.
Wildcard

Odpowiedzi:

28

Wiele z tych narzędzi wykonać pracę bezpośrednio z drzewo składniowe (czy raczej bezpośredniej wizualizacji jeden-do-jednego z nich). Że zawiera Blockly, które widziałem, a inne języki i redaktorów blokowe oparte jak to ( Scratch , ołówek Kod / Kropelka , Snap! , GP , marmurowa Grace , i tak dalej).

Systemy te nie pokazują tradycyjnej reprezentacji wykresów wierzchołków i krawędzi, z powodów wyjaśnionych gdzie indziej (przestrzeń, a także trudność interakcji), ale bezpośrednio reprezentują drzewo. Jeden węzeł lub blok jest dzieckiem innego, jeśli jest bezpośrednio, fizycznie wewnątrz elementu nadrzędnego.


Zbudowałem jeden z tych systemów ( Tiled Grace , papier , papier ). Zapewniam cię, że bardzo bezpośrednio współpracuje z AST: to, co widzisz na ekranie, to dokładna reprezentacja drzewa składni jako zagnieżdżonych elementów DOM (a więc drzewa!).

Zrzut ekranu zagnieżdżonego kodu Tace Grace

To jest AST jakiegoś kodu. Root jest węzłem wywołania metody „for… do”. Ten węzeł ma kilka elementów potomnych, zaczynając od „_ .. _”, który sam ma dwa elementy potomne, węzeł „1” i węzeł „10”. To, co pojawia się na ekranie, jest dokładnie tym, co wyrzuca kompilator kompilatora w środku procesu - tak zasadniczo działa system.

Jeśli chcesz, możesz pomyśleć o tym jako o standardowym układzie drzewa z krawędziami skierowanymi w stronę ekranu (i zasłoniętymi blokiem przed nimi), ale zagnieżdżanie jest równie ważnym sposobem pokazania drzewa jak wierzchołka diagram.

Będzie również „wykonywać podróż w obie strony od źródła do wykresu węzła, a następnie w razie potrzeby ponownie do źródła”. W rzeczywistości możesz to zobaczyć, klikając „Widok kodu” na dole. Jeśli zmodyfikujesz tekst, zostanie on ponownie przeanalizowany, a powstałe drzewo będzie renderowane w celu ponownej edycji, a jeśli zmodyfikujesz bloki, to samo dzieje się ze źródłem.


Pencil Code robi w zasadzie to samo z lepszym interfejsem . Bloki, których używa, to graficzny widok CoffeeScript AST. Podobnie jak inne systemy oparte na blokach lub kafelkach, chociaż niektóre z nich nie sprawiają, że aspekt zagnieżdżania jest tak wyraźny w reprezentacji wizualnej, a wielu nie ma za sobą rzeczywistego języka tekstowego, więc „ „drzewo składniowe” może być nieco iluzoryczne, ale zasada istnieje.


Czego brakuje, to to, że systemy te naprawdę bezpośrednią współpracę z drzewo składniowe. To, co widzisz i którym manipulujesz, to wydajne przestrzennie renderowanie drzewa, w wielu przypadkach dosłownie AST generowany przez kompilator lub parser.

Michael Homer
źródło
6

Co najmniej dwa powody:

  1. Ponieważ kod źródłowy jest o wiele bardziej zwięzłą reprezentacją. Ułożenie AST jako wykresu zajęłoby znacznie więcej wizualnych nieruchomości.

    Programiści nagradzają posiadanie jak największej ilości kontekstu - tzn. Jednoczesne wyświetlanie na ekranie tylu kodów jednocześnie. Kontekst pomaga im lepiej zarządzać złożonością. (To jeden z powodów, dla których wielu programistów używa tych zwariowanych małych czcionek i ogromnych 30-calowych ekranów).

    Gdybyśmy próbowali wyświetlić AST jako wykres lub drzewo, wówczas ilość kodu, który można zmieścić na jednym ekranie, byłaby znacznie mniejsza niż wtedy, gdy byłby reprezentowany jako kod źródłowy. To ogromna strata dla wydajności programistów.

  2. AST są przeznaczone do programowania kompilatora, a nie dla łatwego zrozumienia przez programistów. Jeśli wziąłeś istniejącą reprezentację AST i wyświetliłeś ją wizualnie, prawdopodobnie programiści byliby trudniej ją zrozumieć, ponieważ AST nie zostały zaprojektowane tak, aby ułatwić programistom naukę.

    W przeciwieństwie do tego, kod źródłowy jest zwykle 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. Aspekty muszą być rozumiane tylko przez twórcó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. Nie wygrana.

Zobacz także /software//q/119463/34181 z kilku dodatkowych potencjalnych powodów.

DW
źródło
2
„Dla kontrastu, kod źródłowy został zaprojektowany tak, aby był czytelny / zrozumiały dla programistów” - kontrprzykład: większość esolangów, Perl, Lisp
John Dvorak
1
„Ponieważ kod źródłowy jest o wiele 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” - są to argumenty przeciwko wszystkim wizualnym PL, ale nie pomagają w wyjaśnieniu rozróżnienia, którego dotyczy OP.
Raphael
„(To jeden z powodów, dla których wielu programistów używa tych zwariowanych małych czcionek i ogromnych 30-calowych ekranów.)” - jeśli potrzebujesz dużego ekranu, aby wyświetlić wystarczającą ilość kontekstu, może kodujesz spaghetti?;)
Raphael
1
@Raphael Być może, ale rzucić na to mniej wysiłku niż refaktoryzacja!
Kroltan
3
@JanDvorak, ... LISP jest kontrprzykładem, ponieważ AST jest językiem - co daje mu siłę wyrazu; pisanie kodu LISP, który rekompiluje twój drugi kod LISP, jest tak proste, jak pisanie kodu, który modyfikuje standardowe struktury danych LISP ... dokładnie takie, w jakich zapisany jest kod LISP . Jest powód, dla którego trwał ponad pół wieku - projekt rodziny jest niezwykle wyrazisty. Go musiało mieć głęboko wbudowane rozszerzenia asynchroniczne w język i środowisko wykonawcze; dla Clojure to tylko biblioteka. Zobacz także: Pokonanie średnich .
Charles Duffy,
3

Typowa AST według kompilatorów jest raczej złożona i pełna. Kierowana reprezentacja wykresu szybko stałaby się dość trudna do naśladowania. Ale istnieją dwa duże obszary CS, w których stosuje się AST.

  1. Języki Lisp są w rzeczywistości napisane jako AST. Kod źródłowy programu jest zapisywany jako listy i wykorzystywany bezpośrednio przez kompilator i / lub interpreter (w zależności od używanego wariantu).
  2. Języki modelowania, np. UML, i wiele języków specyficznych dla domeny wizualnej używają notacji graficznych, które są efektywnymi abstrakcyjnymi grafami składniowymi (ASG) na wyższym poziomie abstrakcji niż typowy język ogólnego przeznaczenia AST.
CyberFonic
źródło