Інструменти візуального програмування, чому вони не працюють безпосередньо з AST безпосередньо?

Я знайшов кілька інструментів візуального програмування з відкритим кодом, таких як Blockly та друзі, та інші проекти, розміщені в Github, але не вдалося знайти жодного, який би працював безпосередньо з абстрактним синтаксичним деревом.

Чому так?

Я запитую, бо коли я виявив, що кожен компілятор там має фазу в процесі компіляції, де він аналізує вихідний код на AST, мені було очевидно, що деякі візуальні засоби програмування можуть скористатися цим, щоб дати програмістам шляхи редагувати AST безпосередньо візуально, а також здійснити зворотну подорож від джерела до вузла-графіка, а потім знову повернутися до джерела, коли це потрібно.

Наприклад, можна подумати, що від JavaScript AST Visualizer до фактичного інструмента візуального програмування JavaSript не дуже велика різниця.

Отже, чого я пропускаю?

Багато з цих інструментів роблять роботу безпосередньо з абстрактним синтаксичним деревом (або , вірніше, пряма візуалізацією один-до-одного з нього). Це включає в себе блок, які ви вже бачили, і інші блоки на основі мов і редактор , це подобається ( Подряпини , олівець код / Капелька , Snap! , GP , Плитковий Грейс , і так далі).

Ці системи не показують традиційного представлення вершин і крайових графіків з причин, пояснених в інших місцях (простір, а також труднощі взаємодії), але вони безпосередньо представляють дерево. Один вузол, або блок, є дитиною іншого, якщо він знаходиться безпосередньо, фізично всередині батьків.

Я побудував одну з цих систем ( Черепиця Грейс , папір , папір ). Можу запевнити, що дуже сильно працює з AST безпосередньо: те, що ви бачите на екрані, - це точне зображення синтаксичного дерева, як вкладених елементів DOM (так, дерево!).

Це AST деякого коду. Корінь - це вузол виклику методу "for ... do". У цьому вузлі є кілька дітей, починаючи з "_ .. _", який сам має двох дітей, вузол "1" та вузол "10". Що з'являється на екрані - це саме те, що сервер компілятора виплює в середині процесу - саме в цьому принципі працює система.

Якщо вам подобається, ви можете розглядати це як стандартний макет дерева, ребра, спрямовані на екран до вас (і затиснуті блоком перед ними), але вкладення є таким же правильним способом показу дерева як вершини діаграма.

Він також "зробить зворотну поїздку від джерела до вузла-графіка, а потім знову повернеться до джерела, коли це необхідно". Насправді ви можете бачити це, коли натискаєте "Перегляд коду" внизу. Якщо ви модифікуєте текст, він буде повторно проаналізований, а отримане дерево буде надано вам знову редагувати, а якщо ви модифікуєте блоки, те ж саме відбувається і з джерелом.

Код олівця робить по суті те ж саме, що є, в даний момент, кращим інтерфейсом . Блоки, які він використовує, - це графічний вигляд CoffeeScript AST. Так само, як і інші системи на основі блоків або плиток, за великим рахунком, хоча деякі з них не роблять вкладений аспект настільки чітким у візуальному зображенні, а багато хто не мають фактичної мови тексту за ними, так що " синтаксичне дерево "може бути трохи ілюзорним, але принцип є.

Те , що ви НЕ вистачає, то, що ці системи дійсно є безпосередньо роботи з абстрактним синтаксичним деревом. Те, що ви бачите та маніпулює, - це простоефективна візуалізація дерева, у багатьох випадках буквально AST створює компілятор або аналізатор.

Принаймні дві причини:

1. Тому що вихідний код є набагато більш стислим поданням. Покладання AST у вигляді графіка потребує значно більшої візуальної нерухомості.

   Програмісти виграють, маючи якомога більше контексту, тобто маючи стільки коду, що одночасно на екрані. Контекст допомагає їм краще керувати складністю. (Це одна з причин, чому багато програмістів використовують ці шалені маленькі шрифти та величезні 30-дюймові екрани.)

   Якби ми намагалися відобразити AST як графік або дерево, то кількість коду, який ви могли помістити на одному екрані, була б набагато меншою, ніж тоді, коли вона представлена ​​як вихідний код. Це величезна втрата для продуктивності розробника.

2. AST призначені для програмування компілятора, а не для легкого розуміння програмістами. Якщо ви взяли існуюче представлення AST і відобразили його візуально, розробникам, ймовірно, було б важче зрозуміти, оскільки AST не були розроблені так, щоб розробникам було легко навчитися.

   На відміну від цього, вихідний код, як правило , розроблений таким, щоб читати / зрозуміти розробникам; це, як правило, важливі критерії дизайну вихідного коду, але не для AST. AST повинні розуміти лише автори-компілятори, а не щоденні розробники.

   І, у будь-якому випадку, мова AST була б другою мовою, яку розробники мають вивчати, окрім мови-джерела. Не виграш.

Дивіться також /software//q/119463/34181 про деякі додаткові можливі причини.

Типовий компілятор AST досить складний і багатослівний. Спрямоване представлення графіків швидко стане досить важким для дотримання. Але є дві великі області ЦС, де використовуються AST.

1. Мови Lisp насправді пишуться як AST. Вихідний код програми записується у вигляді списків і безпосередньо використовується компілятором та / або інтерпретатором (залежно від того, який варіант використовується).
2. Мови моделювання, наприклад, UML та багато мов, що мають особливу візуальну область, використовують графічні позначення, які є ефективними абстрактними графами синтаксису (ASG) на більш високому рівні абстракції, ніж типова загальновизнана мова AST.