Инструменты визуального программирования, почему они не работают с AST напрямую?

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

Почему это?

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

Например, можно подумать, что от JavaScript AST Visualizer до реального инструмента визуального программирования JavaSript нет большой разницы.

Итак, что мне не хватает?

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

Эти системы не показывают традиционное представление графа вершин и ребер по причинам, объясненным в другом месте (пространство, а также сложность взаимодействия), но они непосредственно представляют дерево. Один узел или блок является дочерним по отношению к другому, если он находится непосредственно, физически внутри родительского элемента.

Я построил одну из этих систем ( Tiled Grace , бумага , бумага ). Уверяю вас, он очень тесно работает с AST напрямую: то, что вы видите на экране, является точным представлением синтаксического дерева в виде вложенных элементов DOM (а значит, дерева!).

Это AST некоторого кода. Корень - это узел вызова метода "for ... do". У этого узла есть несколько дочерних элементов, начиная с «_ .. _», который сам имеет двух дочерних элементов: узел «1» и узел «10». То, что появляется на экране, - это то, что серверная часть компилятора выкладывает в середине процесса - это принципиально, как работает система.

Если вам нравится, вы можете думать об этом как о стандартном макете дерева с ребрами, направленными наружу на экран (и перекрытыми блоком перед ними), но вложение является таким же правильным способом показать дерево как вершину. диаграмма.

Также будет выполнено «обратное путешествие от источника к графу узлов, а затем снова при необходимости к источнику». На самом деле, вы можете увидеть, что происходит, когда вы нажимаете «Вид кода» внизу. Если вы измените текст, он будет повторно проанализирован, и результирующее дерево будет отредактировано для вас, чтобы редактировать снова, и если вы измените блоки, то же самое произойдет и с источником.

Pencil Code делает то же самое с улучшенным интерфейсом . Блоки, которые он использует, представляют собой графическое представление CoffeeScript AST. То же самое можно сказать и о других системах на основе блоков или плиток, хотя в некоторых из них аспект визуализации не настолько ясен в визуальном представлении, а у многих за ними нет текстового языка, поэтому синтаксическое дерево "может быть немного призрачным, но принцип есть.

То , что вы не хватает, то, что эти системы действительно являются непосредственно работы с абстрактным синтаксическим деревом. То, что вы видите и манипулируете, - это рендеринг дерева с эффективным использованием пространства, во многих случаях буквально AST, создаваемый компилятором или парсером.

Как минимум две причины:

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

   Программисты выигрывают, имея как можно больше контекста, то есть, имея на экране как можно больше кода одновременно. Контекст помогает им лучше управлять сложностью. (Это одна из причин, почему многие программисты используют эти сумасшедшие маленькие шрифты и огромные 30-дюймовые экраны.)

   Если бы мы попытались отобразить AST в виде графика или дерева, то объем кода, который вы могли бы разместить на одном экране, был бы намного меньше, чем когда он представлен в виде исходного кода. Это огромная потеря для производительности разработчиков.

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

   В отличие от этого , исходный код , как правило , является разработано , чтобы быть читаемыми / понятно разработчиками; это обычно является критическим критерием проектирования для исходного кода, но не для AST. AST должны понимать только авторы компилятора, а не обычные разработчики.

   И, в любом случае, язык AST будет вторым языком, который разработчики должны изучать, помимо исходного языка. Не победа

См. Также /software//q/119463/34181 для некоторых дополнительных потенциальных причин.

Типичный AST компиляторами довольно сложный и многословный. Представление ориентированного графа быстро станет довольно сложным для понимания. Но есть две большие области CS, где используются AST.

1. Языки Лисп фактически написаны как AST. Исходный код программы пишется в виде списков и напрямую используется компилятором и / или интерпретатором (в зависимости от того, какой вариант используется).
2. Языки моделирования, например UML, и многие языки, специфичные для визуальной области, используют графические обозначения, которые являются эффективными абстрактными синтаксическими графами (ASG) на более высоком уровне абстракции, чем типичный язык общего назначения AST.