Написание парсера для смешанных языков

Question

Я пытаюсь написать анализатор, который может анализировать смешанные языки и генерировать AST. Сначала я попытался создать его с нуля самостоятельно на Java и потерпел неудачу, потому что это довольно сложная тема для начинающего Parser. Затем я googled и нашел http://www2.cs.tum.edu/projects/cup/examples.php и JFlex.

Вопрос сейчас: что является лучшим способом сделать это?

Например, у меня есть Codefile, который содержит несколько тегов, JS-код и некоторый код $ CMS_SET (x, y) $. Лучше всего решить эту проблему, чтобы определить грамматику для всех этих вещей в CUP и позволить CUP генерировать Parser на основе моего грамматика, который может анализировать эти смешанные языковые файлы и генерировать и AST Tree из него?

Благодарим за все полезные ответы. :)

EDIT: мне нужно сделать это в Java ...

Answer 1

Эта тема довольно сложно даже для специалиста в этой области, я считаю себя; проверьте мою биографию.

Первый вопрос заключается в создании отдельных парсеров для каждого подъязыка. Первое, что вы обнаружите, это то, что определение парсеров для определенных языков на самом деле сложно; вы можете прочитать бесконечный список SO-запросов для «могу ли я получить парсер для X» или «как исправить мой парсер для X». В основном я думаю, что эти запросы никуда не денутся; синтаксические синтаксические анализаторы не очень хороши, вам нужно крутить грамматики и синтаксические анализаторы, чтобы заставить их работать на реальных языках, нет такой вещи, как «чистый HTML», документы стандартов не согласуются, и ваш клиент всегда имеет какой-то поворот в его коде, к которому вы не готовы. Наконец, есть глюки, связанные с кодировкой набора символов, изменениями в концах новой строки и препроцессоры для усложнения анализа синтаксического анализа. Препроцессор C++ намного сложнее, чем вы могли бы подумать, и вы должны иметь это право. Самый простой способ победить эту проблему - найти генератор парсера с уже предопределенными языками. ANTLR имеет кучу уже устаревших ANTLR3; нет уверенности в том, что эти синтаксические анализаторы надежны, не говоря уже о совместимости для ваших целей.

CUP не является особенно полезным генератором парсера; ни один из генераторов парсеров LL (x) или LALR (x) не очень полезен, потому что никакие реальные langauge не соответствуют категориям вещей, которые они могут анализировать. Следствие: бесконечный поток запросов (на SO!) Для помощи «разрешения конфликта с уменьшением смены» или «устранения правильной рекурсии». Единственным синтаксическим анализатором IMHO, который выдержал испытание временем, является генератор парсера GLR (я слышу хорошие вещи о GLL, но это довольно недавно). Мы сделали 40 языков с один Генератор парсера GLR, включая продукцию IBM COBOL, полный C++ 14 и Java8.

Вторая проблема заключается в создании АСТ. Вы можете передать код процесса построения АСТ, но он быстро стареет, когда вам приходится часто менять грамматики и/или у вас есть много грамматик, как вы эффективно созерцаете. Это вы можете побить свой пот. (Мы выбрали push the problem of building ASTs into the parser, поэтому нам не нужно было вкладывать энергию в построение грамматики, для этого ваш синтаксический анализатор должен предложить вам эту помощь, и ни одна из них не будет выполнена).

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

Но все вышеперечисленное не является проблемой.

Разбор неудобен, но лишь небольшая часть того, что вам нужно для анализа ваших программ любым интересным способом; вам нужны таблички с символами, контроль и анализ потока данных, а может быть, анализы с точки зрения анализа, а техническая информация по этим вопросам будет захлагать перечисленные выше работы. См. Мое эссе «Жизнь после парсинга» (google или через мою биографию) для долгого обсуждения того, что еще вам нужно.

Короче говоря, я думаю, вы откусили огромную задачу только в «разборе», и вы даже не сказали нам, что вы намерены делать с результатом. Вы можете начать этот путь, но очень мало людей преуспели; моя команда провела более 50 человеко-лет инженерных наук PhD, чтобы добраться туда, где мы находимся, и мы едва ли закончили.

Java не будет делать решение более легким или сложным; langauge, в котором вы решаете все вышеперечисленное, не имеет значения.