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

Question

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

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

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

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

Спасибо!

Answer 1

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

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

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

Возможно, вы также захотите взглянуть на ANTLR's древовидные грамматики.

Answer 2

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

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

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

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

Я работаю над профессиональный инструмент для управления программами.Если мы распечатали AST, мы делаем вышеописанное.В основном отдельные AST слишком сложны, чтобы рассматривать их на практике, поэтому мы почти никогда не распечатываем весь AST, в лучшем случае только узел и несколько дочерних элементов в глубине.Наш инструмент не обменивается Работает с кем угодно (см. Причины выше :), но делает просто прекрасно создает его в памяти, делая с ним невероятные вещи по соображениям анализа или трансформации, а затем либо просто удаляю его (нет необходимости отправлять его куда-либо). или регенерировать текст на исходном языке из дерева.[Последнее означает, что вам нужна защита от синтаксического анализа или "красивая печать" технология]

Answer 3

Ожидаются конкретные стандарты, в то время как стандарты более общего назначения также могут быть уместны.Айра Бакстер уже упоминался GXL, и РДФ можно также добавить, просто что для этого потребуется соответствующая онтология и она больше ориентирована на семантику, чем на синтаксис.Все еще может быть вариант для расследования.

Что касается конкретных стандартов, Айра Бакстер уже упоминал ASTM, другой, хотя он скорее нацелен на определенный тип языка программирования (logic languages), является стандарт для семантического / концептуального графа, известный как ISO‑IEC 24707 2007.

Не стандарт сам по себе, а документ по этому вопросу: К переносимым представлениям исходного кода С использованием XML .

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