Здравствуйте, koodeer, Вы писали:

K>Вот здесь я вычитал, что xslt-процессор Saxon генерирует код трансформации в зависимости от путей доступа (осей xml), которые действительно используются. Не знаю, даёт ли это реальный выигрыш в производительности, но выглядит разумно.

K>Позволяют ли какие-нибудь генераторов парсеров декларативно задавать такую возможность генерации?
K>Интересует, в первую очередь, Nemerle.PEG.
K>Nitra предлагает что-нибудь подобное?

По ссылке описываются оптимизации связанные с XPath/XSLT. Они не особо применимы к Nemerle.PEG и Nitra. "Оси" это нечто вроде элементов гомогенного AST-а (т.е. AST с универсальной структурой). Nemerle.PEG вообще не предоставляет средства создания AST. Вместо этого он предоставляет модель обходчика (аналогичную SAX-модель в XML), и уже пользователь сам решает нужно ли ему вообще создавать AST и какой.

Nitra создает низкоуровневый AST в виде двух int-массивов. Информация в них запакована и может читаться только последовательно (но с возможностью пропускать подправила при обходе, за счет чего можно переходить к чтению нужных подузлов). И AST в Nitra гетерогенный (т.е. для каждого правила структура уникальна и описывается в метаинформации). Вот при создании объектного AST (мы его называем материализованным) мы используем принципы ленивости. Плюс обратных ссылок (ссылок на родители) у нас нет. Если нужно иметь ссылки на родителей можно передавать их через параметры методов при обходе.

В общем, эти вещи трудно сравнивать.

Проблемы производительности парсинга намного больше упираются в алгоритмические вопросы нежели в вопросы обхода AST-а. В XML вопрос парсера не так важен, так как синтаксически язык очень прост и может быть отпарсен LL(1)-парсером. А вот обход является важным, так как формат зачастую используется не как база для языка (XAML, конфиг и т.п.), а как примитивная СУБД — хранилище данных.

Nitra же это средство создания именно языков программирование. Ее главные черты — это всеядность по отношению к грамматикам (не надо приводить грамматики к LL(k) или LALR(1)), динамическая расширяемость, автоматическая реализация IDE-сервисов, средства манипулирования AST-ом, а в будущем — автоматизация всех аспектов разработки расширяемых языков (типизация, трансформация кода в тот же или другие языки). Универсальный XML-парсер на Nitra, конечно, сделать можно. Но он вряд ли будет быстрее рукописного (специализированного) варианта. Вот в случае сложных языков вроде C#, Java, C++ эффективность будет страдать меньше, так как продвинутые алгоритмы парсинга для этих языков очень даже востребованы.