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

25

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

Почему это?

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

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

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

rraallvv
источник
10
AST очень многословны и не очень удобны для программирования. Они были предназначены для компиляторов, а не для программистов.
Юваль Фильмус
1
Что вы подразумеваете под «работать напрямую с абстрактным синтаксическим деревом»? Возможно, все основанные на блоках инструменты, такие как Blockly, редактируют AST: они представляют ребра путем вложения (или укладки, если вы предпочитаете видеть это таким образом), и пользователь может редактировать дерево с помощью, скажем, перетаскивания.
Майкл Гомер
Это отличный вопрос, который многие из нас, кто любит компиляторы, задавали. Я думаю, что короткий ответ таков: если бы вы могли сделать это и сделать это удобным для пользователей, люди бы использовали это. Единственная проблема в том, что это большое «если».
Мердад
2
Вы смотрели в Лисп ? «[Это] не так, что у Lisp странный синтаксис, а у Lisp нет синтаксиса. Вы пишете программы в деревьях разбора, которые генерируются в компиляторе при разборе других языков. Но эти деревья разбора полностью доступны для ваших программ. Вы можете писать программы, которые ими манипулируют ».
Wildcard

Ответы:

28

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

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


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

Снимок экрана с вложенным кодом Tiled Grace

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

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

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


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


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

Майкл Гомер
источник
6

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

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

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

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

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

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

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

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

DW
источник
2
«Напротив, исходный код предназначен для чтения / понимания разработчиками», - контрпример: большинство esolangs, Perl, Lisp
Джон Дворжак
1
"Потому что исходный код - гораздо более краткое представление."; «Язык AST будет вторым языком, который разработчики должны изучать, помимо исходного языка» - это аргументы против всех визуальных PL, но они не помогают объяснить различие, о котором беспокоится OP.
Рафаэль
«(Это одна из причин, почему многие программисты используют эти сумасшедшие маленькие шрифты и огромные 30-дюймовые экраны.)» - если вам нужен большой экран для просмотра достаточного количества контекста, возможно, вы занимаетесь спагетти-кодированием?;)
Рафаэль
1
@ Рафаэль Возможно, но потратить на это меньше усилий, чем рефакторинг!
Кролтан
3
@JanDvorak, ... LISP является контрпримером, потому что AST - это язык, который дает ему выразительную силу; Написание кода LISP, который перекомпилирует ваш другой код LISP, так же просто, как написание кода, который изменяет стандартные структуры данных LISP ... именно в этом и заключается код LISP . Есть причина, по которой он длился более полувека - дизайн семьи необычайно выразителен. В Go должны были быть установлены асинхронные расширения вглубь языка и среды выполнения; для Clojure это просто библиотека. Смотрите также: Beating the Average .
Чарльз Даффи
3

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

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