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

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?

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!).

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ę są 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.

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.

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.