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

VD>Нитра не закладывается на то как будет расширяться зык. Но, да, расширяемый язык должен иметь внятное и детерминированную политику расширения. Если расширение вводится синтаксической конструкцией вроде using-а, она должна быть однозначной, ведь расширение будет загружаться на не последующей стадии, а прямо во время парсинга.

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

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

syntax my_sql_extension (statement_list)
// my_sql_extension - имя расширения
// statement_list - правило, которое будет стартовым. Оно из родительской грамматики родительской грамматики.
// записанные правила добавляются к родительской грамматике
{
    closed_statement = 'identifier' '=' sql_expression; 

    sql_expression = "SELECT" actual_parameter actual_parameter_list "FROM" 'identifier' 
        sql_where_caluse sql_group_by_caluse sql_order_caluse;

    ...;
}
void foo1()
{
// здесь расширение не подключено
}
void bar()
{
    using my_sql_extension;
    sqlResult = SELECT a, sin(x) FROM myTable WHERE x = foo(a, b, c, d) GROUP BY t;
}
void foo2()
{
// здесь расширение не подключено
}

Здесь и описание грамматики, и её подключение должно быть однозначным?

VD>Грамматику нужно писать вручную. По ней будет парсер будет сгенерирован автоматически.
VD>Вот пример грамматики шарпа. Пишешь подобную для нужного языка, помещаешь в проект, компилируешь и получаешь готовый парсер.

A>>Если строить парсеры для предварительного разбора (tentative parsing) автоматически на основе исходной грамматики, то приседаний не будет.

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

A>>В процессе типизации нужно будет ещё производить инстанциирование шаблонов, чтобы парсить конструкции типа MyTemplate<param>::typeOrVariable.

VD>Ну, шаблоны можно типизировать исключительно в их конкретных воплощениях (не люблю я этот новояз — "инстанциирование"). По сути шаблоны это АСТ-шные макросы. По сему тут ничего другого и не придумаешь.

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

A>>Будет ли в этом случае рантайм ошибка или же предлагается как-то заранее проверить систему типов на однозначность?

VD>Расширяемость не дает возможность проверять даже однозначность грамматики (да и вычислительно это вряд ли возможно). В рантайме (на конкретном дереве разбора) это делается без проблем.

VD>>>Вообще, парсинг языков вроде С++ должен радикально упроститься с использованием генерализованных парсеров (так что ли их назвать?) именно потому что не нужно никаких танцев с бубнами. Можно получить неоднозначное дерево разбора соответствующее контекстно-свободной грамматике, а потом разрешить неоднозначности использую уже полное дерево разбора.

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

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