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

A>А как это сейчас реализовано?

Пока никак. Есть только базовый API позволяющий сформировать так размазываемый композитную грамматику из нескольких других. Нужно еще создать некую закладку в парсере которая позволит после распознавания некоторой конструкции передать управление внешнему обработчику в котором будет сформирована новая композитная грамматика с помощью которой далее пойдет парсинг.

Откровенно говоря до этого пока не дошли руки. Народу мало, но задач много.

A>Как задать то, что конструкция using MyLanguage; вводит новый язык. В документации к нитре я этого не смог найти. В Nemerle, насколько я помню, это происходит в pre parser — там захордкожена конструкция using ...; Или как в нитре задать новую конструкцию для расширения? Например import langauge MyLanguage;

Пока что можно только вручную собрать композитную грамматику из нескольких внешних грамматик (перед начало парсинга). Точнее собрать ее можно в любое время. Мы специально проектировали и реализовывали все так, чтобы грамматику можно было махнуть на ходу в любое время.

Пожалуй что поставим себе задачу подмены грамматики в ближайшие планы.

A>Возможно ли задать грамматику и подключить её в том же файле?

Нет. Грамматика должна быть скомпилирована перед использованием.

A>Если такие парсеры будут генерироваться атоматически на основе исходной полной грамматики языка, пользователь не будет тратить время. Это будут детали реализации парсера. Для каких частей грамматики генерировать такие парсеры можно понять по зависимостям атрибутов, если грамматика атрибутная.

Ты задолбаешся аннотировать свои грамматики, чтобы все генерировалось автоматически. На мой взгляд — это тупиковый путь. Как костыль при рукопашной реализации еще потянет, но не более того.

A>Имелось ввиду то, что для типизации MyTemplate<param>::type variable; нужно раскрыть шаблон. Для того, чтобы раскрыть шаблон нужно не только подставить типы, но ещё найти тело шаблона с учетом вывода типов, частичных специализаций и SFINAE.

Ну, да. Типизация в плюсах не простое занятие. Но причем тут парсинг?

A>Так задача разрешения неоднозначности переносится со стадии парсинга на типизацию, но никуда не исчезает.

Естественно. Чудес не бывает. Но всегда проще решить две отдельные задачи, смешать их в одну более сложную. Сложности имеют тенденцию перемножаться. По сему их разделение есть главный способ борьбы со сложностью.

A>С другой стороны можно описывать атрибутную грамматику с предикатами, которая будет однозначна.

Это если грамматика однозначна.

С++ все очень просто. У него тупо контекстно-зависимая грамматика. Невозможно выделить однозначную КСГ. Зато можно создать конфликтную КСГ. Если язык позволяет разрешить неоднозначности за счет синтаксических предикатов, то можно применять их. Но С++ опять же не тот случай. По сему или куча приседаний или парсинг с конфликтами и отдельное их устранение.

VD>>А вот то, что даже разные Майкрософты не могут ослить последних стандартов С++ очень сильно печалит.
A>У них много старого кода, который они не хотят переписать с нуля. А для интеллисенс вообще используют сторонний парсер.

Их оправдания меня не интересуют. Я констатирую факт. В языках где думали о парсинге заранее таких проблем нет.