Стандартный формат для конкретных и абстрактных деревьев синтаксиса

Question

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

Существует ли стандартный формат описания конкретных или абстрактных деревьев синтаксиса? Поддерживаются ли какие-либо широко используемые цепочки инструментов в этих форматах?

У меня нет конкретного целевого языка программирования. Любой популярный будет делать для прототипа, но я бы предпочел, чтобы я хорошо знал: Python, C#, Javascript или C/C++.

Мне нужна возможность запускать исходный файл через инструмент или библиотеку и возвращать оба дерева. В идеальном мире было бы практично запускать этот инструмент по коду, поскольку он редактируется пользователем и допускает ошибки. Опять же, я просто пытаюсь разработать прототип, поэтому эти требования довольно слабы.

Спасибо!

Answer 1

В our project мы определили метамодель AST в UML и используем ANTLR (Java) для заполнения модели. Мы также сохраняем информацию о токенах из ANTLR после разбора, но мы еще не пытались обновить базовый текстовый файл с изменениями, внесенными в модель.

У этого есть отвратительные накладные расходы (в инфраструктуре, например Eclipse UML2/EMF), но наша цель - использовать высокоуровневые инструменты для разработки на основе моделей (MDD, MDA) в любом случае, поэтому мы решили использовать это на каждом уровне.

Я думаю, что один из наших учеников однажды сыграл с OpenArchitectureWare и смог автоматически получить изменения сгенерированного редактора на основе Eclipse в дерево синтаксиса (не связанное с моделью UML выше), но я не знаю, подробности об этом.

Вы также можете посмотреть ANTLR's древовидные грамматики.

Answer 2

Исследовательское сообщество решило, что обмен графами является правильным решением при перемещении информации из одного инструмента анализа программ в другой. См. http://www.gupro.de/GXL

Совсем недавно OMG определила стандарт для обмена абстрактными синтаксическими деревьями. См. http://www.omg.org/spec/ASTM/1.0/Beta1/

Эта проблема, кажется, будет решена снова и снова. Есть полдюжины предложений «инструментальных шин», сделанных за последние годы , что все это решило, и никто не обгонял промышленность. Проблема заключается в том, что а) легко представить АСТ, используя любые типы вложенных обозначений [круглые скобки, такие как LISP, , такие как XML, ...], поэтому люди легко сбрасывают собственное решение, и b) для одного инструмента обмена АСТ с другим, они должны в принципе соглашаться с тем, что означает AST-узлы; , но большинство АСТ довольно случайно получены из конкретной технологии грамматики/разбора, используемой каждым инструментом, и почти всегда не согласны с тем, что между инструментами. Итак, я видел очень мало инструментов, которые осмысленно меняют АСТ.

Если вы делаете хобби вещь, я бы придерживаться сюсюкать-как кодирования деревьев, где каждый узел имеет следующий формат: (...) Его легко генерировать, и легко читать.

Я работаю на professional tool to manipulate programs. Если у нас распечатать AST, мы делаем это. Чаще всего АСТ слишком сложны, чтобы на практике смотреть, , поэтому мы вряд ли когда-либо распечатаем весь АСТ, в лучшем случае только узел и несколько детей в глубину. Наш инструмент не обменивает АСТ с кем-либо (см. Выше причины :), но делает только , прекрасно строя его в памяти, делая с ним что-то извиваясь по причинам анализа или причинам трансформации, а затем либо просто удаляет его (нет необходимости отправьте его в любом месте) или регенерируйте исходный язык текста из дерева. [Последнее означает, что вам нужен анти-синтаксический анализ или «красивой печати» technology]

Answer 3

Конкретные стандарты - это ожидание, в то время как более универсальные стандарты также могут быть подходящими. Ира Бакстер уже упоминала GXL и RDF тоже может быть добавлена, просто для того, чтобы она требовала соответствующей онтологии и была более ориентирована на семантический, чем синтаксис. Все еще может быть возможность расследовать.

Для конкретных стандартов, Ira Baxter уже упоминалось ASTM, еще один, хотя он скорее нацелен на конкретный вид языка программирования (логические языки), является a standard for semantic/conceptual graph, известный как ISO‑IEC 24707 2007.

Нестандарт сам по себе, а бумага по этому поводу: Towards Portable Source Code Representations Using XML .

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