Я не могу говорить о том, что Xtext является или делает хорошо.
Я могу поговорить о проблеме разработки надежных инструментов для обработки реальных языков, основываясь на нашем опыте с DMS Software Reengineering Toolkit , который, как мы представляем, является структурой манипулирования .
Во-первых, парсинг реальных языков обычно включает в себя что-то грязное в лексизировании и / или парсинге из-за исторических путей, в которых эти языки развивались. Ява довольно чистая. C # имеет контекстно-зависимые ключевые слова и элементарный препроцессор вроде C. С имеет полноценный препроцессор. С ++ классно «трудно анализировать» из-за неясностей в грамматике и махинаций с синтаксисом шаблонов. COBOL довольно уродлив, не имеет справочных грамматик и поставляется на разных диалектах. PHP превратит вас в камень, если вы посмотрите на него, потому что он так плохо определен. (У DMS есть парсеры для всего этого, используемые в гневе на реальных приложениях).
Тем не менее, вы можете проанализировать все это с большинством доступных технологий синтаксического анализа, если попытаетесь достаточно усердно, обычно, злоупотребляя лексером или синтаксическим анализатором для достижения ваших целей (как парни из GNU злоупотребляли Bison для анализа C ++, запутывая лексический анализ поиск таблицы символов - хороший уродливый случай. Но чтобы правильно понять детали языка, нужно приложить немало усилий, а справочные руководства являются лишь приблизительным приближением к истине относительно того, что на самом деле принимают компиляторы.
Если Xtext имеет приличный механизм синтаксического анализа, то, вероятно, это можно сделать с помощью Xtext. Краткое прочтение сайта Xtext звучит так, как будто лексеры и парсеры довольно приличны. Я ничего не видел о "Семантическом Предикате"; у нас они есть в DMS, и они спасают жизнь в некоторых действительно темных уголках разбора. Даже используя действительно хорошую технологию синтаксического анализа (мы используем анализаторы GLR), было бы очень трудно проанализировать объявления данных COBOL (извлекая их структуру вложенности во время анализа) без них.
У вас есть интересная проблема в том, что ваш язык еще недостаточно определен. Это сделает ваши начальные парсеры несколько грязными, и вы будете их много пересматривать. Вот где вам помогает мощная технология синтаксического анализа: если вы можете легко пересмотреть свою грамматику, вы можете сосредоточиться на том, как вы хотите, чтобы ваш язык выглядел, а не на борьбе с лексером и анализатором. Тот факт, что вы можете изменить определение языка, фактически означает, что если Xtext имеет некоторые ограничения, вы, вероятно, сможете изменить свой синтаксис языка, чтобы он соответствовал без огромного количества боли. ANTLR обладает доказанной способностью анализировать язык практически так, как вы его себе представляете, по модулю обычного количества взломов анализатора.
Что никогда не обсуждается, так это то, что еще нужно для реальной обработки языка. Первое, что вам нужно уметь делать, - это создавать AST, которые ANTLR и YACC помогут вам сделать; Я полагаю, Xtext тоже. Вам также нужны таблицы символов, контроль и анализ потоков данных (как локальных, так и глобальных), а также оборудование для преобразования вашего языка во что-то другое (предположительно, более исполняемый). Делать только таблицы символов вы найдете на удивление сложно; C ++ имеет несколько сотен страниц «как найти идентификатор»; Обобщения Java гораздо сложнее понять, чем вы могли бы ожидать. Вы также можете распечатать AST обратно к исходному коду, если вы хотите предложить рефакторинг. (РЕДАКТИРОВАТЬ: Здесь и ANTLR, и Xtext предлагают то, что равнозначно генерации кода на основе текстовых шаблонов).
Все же это сложные механизмы, которые занимают столько же времени, если не больше, чем сборка синтаксического анализатора. Причина, по которой DMS существует, не в том, что он может анализировать (мы рассматриваем это просто как ставку в покерной игре), а в том, что все эти другие вещи очень сложны, и мы хотели амортизировать стоимость всего этого (DMS имеет, мы думаем, отличная поддержка для всех этих механизмов, кроме YMMV).
При чтении обзора Xtext кажется, что у них есть некоторая поддержка таблиц символов, но неясно, какие предположения стоят за ним (например, для C ++ вы должны поддерживать множественное наследование и пространства имен).
Если вы уже начали движение по дороге ANTLR и у вас что-то работает, у меня будет соблазн остаться на курсе; Я сомневаюсь, что Xtext предложит вам много дополнительной помощи. Если вам действительно нужен редактор Xtext, то вы, вероятно, можете переключиться на цену реструктуризации имеющейся у вас грамматики (это довольно типичная цена, которую приходится платить при изменении парадигм разбора). Ожидайте, что большая часть вашей работы появится после того, как вы правильно разберетесь в синтаксическом анализаторе. Я сомневаюсь, что вы найдете Xtext или ANTLR здесь совсем другими.