С нового года мы начали работу над Nemerle 2.0 (далее Н2). Общий план работ можно лицезреть тут (если кому-то интересно).

В Н2 мы хотим реализовать синтаксические макросы (макросы позволяющие изменять синтаксис) на основе разрабатываемого нами движка Nemerle.Peg (он же PegGrammar)

Автор: Чистяков Владислав Юрьевич
Дата: 11.12.10

.

PEG позволяет снять большинство ограничений в области расширения синтаксиса. В Н2 планируется полностью отказаться от парсера в пользу макросов нового поколения. Мы уже знаем как их реализовать, но остаются сомнения в самом синтаксисе новых макросов.

Текущее видение синтаксиса и семантики новых синтаксических макросов описано здесь. Огромная просьба к тем, кто "в теме" прочитать данный документ и покритиковать или предложить свои решения или дополнения. В общем, интересные все мнения. Единственная просьба быть конструктивными и не превращать тему в срач или флуд.

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

Может, все-таки список параметров оставить?
Не все же макры обязательно изменяют синтаксис.

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

W>Может, все-таки список параметров оставить?
W>Не все же макры обязательно изменяют синтаксис.

Дык у не синтаксических макросов синтаксис останется прежним. Мы только планируем ввести необязательную возможность декларации типов параметров.

А список параметров в синтаксических макрах получается дублирует описание.

Попробуй перепиши примеры из ссылки:

macro Class : PTypeDeclaration.Class
  syntax attributes modifiers partial "class" name typeParameters parents constraints "{" members "}" ";"?
  where attributes     = CustomAttributes, 
        modifiers      = Modifiers, 
        partial        = "partial"?, 
        name           = Identifier, 
        typeParameters = TypeParameters, 
        parents        = PExpr*, 
        members        = Member*
{
  PTypeDeclaration.Class(attributes, modifiers, !partial.IsEmpty, name, 
                         typeParameters, parents, constraints, members)
}

и

macro If : PExpr
  syntax "if" "(" cond ")" e1 ";"? "else" e2
{
    <[
      match ($cond : bool)
      {
        | true => $e1
        | _ => $e2
      }
    ]>
}

Получится полный дубляж:

macro Class(attributes, modifiers, partial, name, typeParameters, parents, constraints, members) : PTypeDeclaration.Class
  syntax attributes modifiers partial "class" name typeParameters parents constraints "{" members "}" ";"?
  where attributes     = CustomAttributes, 
        modifiers      = Modifiers, 
        partial        = "partial"?, 
        name           = Identifier, 
        typeParameters = TypeParameters, 
        parents        = PExpr*, 
        members        = Member*
{
  PTypeDeclaration.Class(attributes, modifiers, !partial.IsEmpty, name, 
                         typeParameters, parents, constraints, members)
}

и

macro If(cond, e1, e2) : PExpr
  syntax "if" "(" cond ")" e1 ";"? "else" e2
{
    <[
      match ($cond : bool)
      {
        | true => $e1
        | _ => $e2
      }
    ]>
}

Есть ли в этом смысл?

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

VD>Дык у не синтаксических макросов синтаксис останется прежним. Мы только планируем ввести необязательную возможность декларации типов параметров.

А, понятно — оформление вебстраницы по ссылке ввело в заблуждение: на панели слева ("Содержание") написано "Новый синтаксис макросов", а по тексту — "Новый синтаксис синтаксических макросов"

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

W>А, понятно — оформление вебстраницы по ссылке ввело в заблуждение: на панели слева ("Содержание") написано "Новый синтаксис макросов", а по тексту — "Новый синтаксис синтаксических макросов"

Это шибка. Поправим...

VD>Текущее видение синтаксиса и семантики новых синтаксических макросов описано здесь.

[offtop]
Раз «свежие» мысли не принимаются, то буду придираться
[/offtop]

В виду того в PEG однозначность определяется порядком, если приоритеты у макросов в макро-классе?
Также не нравится то, что параметры могут описаны PegRules. Из-за чего синтаксис макроса размазывается по двум секциям «syntax» и «where». Не лучше ли ограничить параметры только типом или ссылкой на макрос?

Есть ли вторичные макросы-хелперы? Например, макрос разбит на несколько вторичных макросов, но вторичные макросы по отдельности не должны парситься. Или по другому, есть стартовый макрос, и макросы-подправила.

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

_>В виду того в PEG однозначность определяется порядком, если приоритеты у макросов в макро-классе?

Это не очень простой вопрос. Попробую объяснить.

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

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

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

Для операторов будет своя система приоритетов учитывающая не только приоритет, но и ассоциативность.

_>Также не нравится то, что параметры могут описаны PegRules. Из-за чего синтаксис макроса размазывается по двум секциям «syntax» и «where». Не лучше ли ограничить параметры только типом или ссылкой на макрос?

Дык, а где тогда описывать те самые правила?

Типы мы как раз и так прекрасно выведем. Каждое правило описывает возвращаемый тип. Так что это не проблема.

В общем, попробуй предложить свой вариант и подумай нет ли в нем противоречий. Точнее вместе подумаем.

_>Есть ли вторичные макросы-хелперы? Например, макрос разбит на несколько вторичных макросов, но вторичные макросы по отдельности не должны парситься. Или по другому, есть стартовый макрос, и макросы-подправила.

Как описано по ссылке есть макро-классы. Это своего рода модули для групп макросов. В их рамках могут быть макросы (правила) не используемые во вне. Можно ввести модификаторы доступа (public/private).

Кроме того макрос может просто вызвать любую функцию.

Ну, и не стоит забывать, что речь идет о синтаксических макросах. Обычные макросы по прежнему будут описываться в виде эдаких функций принимающих на входе АСТ и (возможно) возвращающих его.

VD>Это не очень простой вопрос. Попробую объяснить.

VD>Расширять можно будет не все что угодно, а только те правила которые исходно помечены как точки расширения.

VD>Для операторов будет своя система приоритетов учитывающая не только приоритет, но и ассоциативность.

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

Сразу скажу я не знаю немерл и не знаю как работают макросы и вообще "полный ноль" в разработке языков.

[offtop]
Поэтому убери, пожалуйста, эту умопомрачительную оценку, я его не достоин. Хочу остаться аноном, только в философии анонам писать нельзя
[/offtop]

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

[offtop]
Вот это — конструктор языков. И предлагаю переименовать Nemerle 2 в Nemerle "Lego".
[/offtop]

А тут одни ограничения: специальные точки расширения, спец. приоритеты операторов, не_знаю_что_еще. В конце концов это выльется в то, что писатель макросов упрется в непонятные ограничения, при попытке написать свой дсл.

Но... Просто на словах, но не реально сделать этот базовый набор макросов, не конфликтующих и корректных, на основе которого можно строить другие DSL,ЯП и тп.

VD>Дык, а где тогда описывать те самые правила?
VD>Типы мы как раз и так прекрасно выведем. Каждое правило описывает возвращаемый тип. Так что это не проблема.
VD>В общем, попробуй предложить свой вариант и подумай нет ли в нем противоречий. Точнее вместе подумаем.
Вообщем я думал, что макрос — это правило с семантикой. Те есть каждое правило это макрос, у которого может быть не тривиальная семантика в блоке "expr".

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

_>[offtop]
_>Поэтому убери, пожалуйста, эту умопомрачительную оценку, я его не достоин. Хочу остаться аноном, только в философии анонам писать нельзя
_>[/offtop]

Оценка за попытку говорить по делу. Окружающие похоже это делать даже не собираются.

_>Судя по логике (моей) синтаксические парсеры должны срабатывать в первую очередь. Можно сказать, синтаксические макросы — это лексемы. Потом вступают в дело макросы, которые изменяют первоначальный АСТ до той степени что в АСТ остаются только базовые типы и функции. То есть синтаксис ограничен только тем, чтобы в конце можно было построить АСТ из базовых операций.

Это не совсем так, но близко к реальности. Лексем не будет просто потому, что PEG позволяет сразу разбирать грамматику. Так что сразу будет АСТ.

Далее то что ты назвал "остаются только базовые типы и функции" в нашем понимании называется типизированным представлением. Или типизированным АСТ. Это последнее независимое от платформы представление кода. Но в нем все же есть типы (классы, перечисления, структуры...) и многое другое.

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

_>[offtop]
_>Вот это — конструктор языков. И предлагаю переименовать Nemerle 2 в Nemerle "Lego".
_>[/offtop]

Зачем?

_>А тут одни ограничения: специальные точки расширения, спец. приоритеты операторов, не_знаю_что_еще. В конце концов это выльется в то, что писатель макросов упрется в непонятные ограничения, при попытке написать свой дсл.

Как раз таки ограничений на расширение синтаксиса почти не будет. Просто надо понимать, суть ограничений не в урезании свободы, а в устранении необходимости делать лишнюю работу. Нельзя начинать любое расширение с написания парсера языка. Проще взять готовый язык и встроить в некотророе место его грамматики свое расширение. Вот это и есть подход Nemerle 2.

_>Но... Просто на словах, но не реально сделать этот базовый набор макросов, не конфликтующих и корректных, на основе которого можно строить другие DSL,ЯП и тп.

Да, вроде бы пока что все выглядит соврешенно реальным. Одна из точек расширения будет "файл". У файла есть свое расширение (в смысле расширение файла). Сделав макросы для разбора, скажем, Паскаля и преобразования его в АСТ немерла мы получаем компилятор Паскаля. Причем Паскаль можно будет использовать в одном проекте с Немерле 2.

Собственно это не мечты. Прототим этого уже работает в Немреле 1. Немерл, как тут уже говорилось, парсит C# 4.

_>Вообщем я думал, что макрос — это правило с семантикой. Те есть каждое правило это макрос, у которого может быть не тривиальная семантика в блоке "expr".

Да. И что из этого следует?

Я еще раз повторюсь, что хотел бы обсудить именно синтаксис самих макросов. Мы хоим сделать максимально понятным и простым процесс добавление вот таких вот новых правил.

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

Каким образом указать, что я хочу подключиться к такой-то точке расширения?
и как определить точку расширения в моём макросе?

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

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

То есть имеется в виду, что будет какой то базовый набор макросов-парсеров
(например, макрос для арифметических выражений +-*/ скобки, макрос для сопоставления/приравнивания)
и на их основе добавив свои парсеры достроить до полноценного dsl
(например, добавив свои макросы для описания функций и сделать простой язык для арифм. вычислений).
Если будут такие "точки расширения", то вопросов больше не имею.

VD>Да, вроде бы пока что все выглядит соврешенно реальным. Одна из точек расширения будет "файл". У файла есть свое расширение (в смысле расширение файла). Сделав макросы для разбора, скажем, Паскаля и преобразования его в АСТ немерла мы получаем компилятор Паскаля. Причем Паскаль можно будет использовать в одном проекте с Немерле 2.

Тут скорее всего не по расширению языка будет выбираться парсер, а скорее всего свойству файла в проекте — "какой парсер у этой единицы трансляции".

_>>Вообщем я думал, что макрос — это правило с семантикой. Те есть каждое правило это макрос, у которого может быть не тривиальная семантика в блоке "expr".
VD>Да. И что из этого следует?

В описанном виде макрос — это начальное правило с параметрами и подправила в которых не могут быть семантические параметры. Что мне делать в случае когда у меня макрос подразумевает использование семантического параметра, который надо описать в подправиле.

Пример (абсолютно сфероконический)
macro ::= param1 param2 rule1
where
rule1 ::= token param3 token
{
supermacro(param1, maram2, param3);
}

Возможно ли использование семантических параметров в секции "where"?

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

P>Каким образом указать, что я хочу подключиться к такой-то точке расширения?
P>и как определить точку расширения в моём макросе?

Это пока что открытые вопросы. Вольфхаунд сейчас работает над расширяемосью. Его работа может повлиять на синтаксис.

Пока что предполагается использовать атрибуты. Скажем если у нас есть макрос TypeDeclaration описывающий конструкции верхнего уровня:

macro TypeDeclaration : PTypeDeclaration
  syntax typeDeclaration
  where  typeDeclaration = Alias / Class / Interface / Struct / Variant 
                         / VariantOption / Delegate / Enum / Expr / Error;
{
  typeDeclaration
}

и мы хотим сделать его точкой расширения, то мы просто дописываем к нему атрибут [Extensible]:

[Extensible]
macro TypeDeclaration : PDeclarationBase
  syntax typeDeclaration
  where  typeDeclaration = Alias / Class / Interface / Struct / Variant 
                         / VariantOption / Delegate / Enum / Expr /  / Error;
{
  typeDeclaration
}

И он становится точкой расширения.
Далее когда в другом макро-классе мы определяем некоторый макрос который должен расширять эту точку расширения, то мы указываем это атрибутом [Extends(TypeDeclaration)]:

[Extends(MainParser.TypeDeclaration)]
macro MyType : PDeclarationBase
  syntax "my" "type" name "{" memrers "}"
  where  name = Identifier, memrers = Member*;
{
  PMyType(name, memrers)
}

Еще раз повторюсь — дизайн не окончательный. Так что если есть какие-то идеи, то излагайте.

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

_>То есть имеется в виду, что будет какой то базовый набор макросов-парсеров
_>(например, макрос для арифметических выражений +-*/ скобки, макрос для сопоставления/приравнивания)
_>и на их основе добавив свои парсеры достроить до полноценного dsl
_>(например, добавив свои макросы для описания функций и сделать простой язык для арифм. вычислений).
_>Если будут такие "точки расширения", то вопросов больше не имею.

Что-то вроде того, но не совсем так просто.

Мы проектируем компилятор Nemerle 2 как фрэймворк для создания статически типизированных не ленивых языков (впрочем, с динамикой, думаю, тоже проблем не будет). Это означает, что мы создаем некий базовый слой предоставляющий универсальные макросы (которые будут писаться на Nemerle 2) позволяющие расширять или заменять синтаксис.

Кроме того мы создаем (описываем) на базе этих макросов синтаксис Nemerle 2 в который вводим так называемые точки расширения. На сегодня планируются следующие точки расширения:
1. На уровне файла — позволяют ввести новый язык, наприме, C#. Это несколько необычная точка расширения, так подстановка расширений в ней будет осуществляться но основании расширений файлов. Можно будет создать сборку содержащую атрибут указывающий, что данная сборка является парсером для определенного расширения (например, .cs). Такой парсер в себе должен содержать как минимум один макрос (правило) расширяющий макрос CompileUnit (описывающий АСТ для одного файла).
2. На уровне списка конструкций верхнего уровня (типов, если вести речь о Nemerle). Это позволит вводить в Nemerle новые типы или любые другие конструкции верхнего уровня (например, глобальные функции).
3. На уровне заголовков типов. Это позволит вводить некоторые синтаксические конструкции между заголовком типа (например, "class A") и его телом.
4. На уровне членов типов. Это позволит вводить свои конструкции внутри типов.
5. На уровне заголовков членов (аналогично п.3).
6. На уровне выражений (используемых в телах членов).

Если понадобятся другие точки расширения, то добавим и их.

Кроме того любой макрос (пользовательский или из стандартной библиотеки) может так же предоставлять точки расширения. Это делает дизайн открытым и рекурсивным.

Благодаря п. 1 кто угодно может создать новый (ли старый) язык в рамках Nemerle. Все что для этого нужно сделать — это реализовать макро-библиотеку, указать в атрибуте уровня сборки, что она ассоциирована с некоторым файловым расширением и не забыть определить в ней макрос расширяющий CompileUnit. Набор макросов из этой сборки должен формировать АСТ из блоков предоставляемых библиотеками Nemerle (в прочем, предварительно можно сформировать и совой АСТ который преобразовать в АСТ Nemerle в отдельном проходе).

Благодаря остальным пунктам можно расширять сам немерл вводя в него новые конструкции или перекрывая старые.

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

_>Тут скорее всего не по расширению языка будет выбираться парсер, а скорее всего свойству файла в проекте — "какой парсер у этой единицы трансляции".

У нас уже есть опыт подключения парсера C# к Nemerle 1. Ассоциация с расширениями работает не плохо. Так что пока что будем придерживаться этого подхода.

_>В описанном виде макрос — это начальное правило с параметрами и подправила в которых не могут быть семантические параметры. Что мне делать в случае когда у меня макрос подразумевает использование семантического параметра, который надо описать в подправиле.

Параметрами макроса может выступать только АСТ (произведенное другими макросами) или константы (строки, числа и т.п.).

Есть три типа макросов:
1. Синтаксические — имеющие свой синтаксис.
2. Макро-атрибуты.
3. Макросы уровня выражения без синтаксиса.

Важно понять, что макро — это не функция которую можно вызвать. Макрос — это функция которая вызывается исключительно компилятором. Ее задача — трансформация кода (и ни что другое).

_>Пример (абсолютно сфероконический)
_>macro ::= param1 param2 rule1
_>where
_>rule1 ::= token param3 token
_>{
_> supermacro(param1, maram2, param3);
_>}

В этом примере "supermacro" будет макросом который раскроется во время компиляции макроса "абсолютно сфероконический". В этом тоже может быть смысл.

Если же нужно произвести некую обработку АСТ, то вместо того чтобы использовать макро, можно воспользоваться обычной функцией. Эта функция может получить входные данные в виде АСТ и/или любых других типов данных и возвратить АСТ которое будет являться результатом работы макроса.

Еще одним вариантом может быть возврат нового АСТ в котором содержится обращение к другому макросу:

macro MyType : PDeclarationBase
  syntax "my" "type" name "{" memrers "}"
  where  name = Identifier, memrers = Member*;
{
  <[ SomeMacroWithoutSyntax($name, $memrers) ]>
}

Знаки "<[" и "]>" в этом примере — это кавычки квази-цитат. Такие цитаты разбираются парсером во время компиляции кода и преобразуются в АСТ. В результате на выходе мы получим код содержащий обращение к макросу SomeMacroWithoutSyntax которому будет передано АСТ содержащееся в параметрах name и memrers.

Квази-цитаты так же позволяют использовать и синтаксические макросы (или для простоты имеющийся синтаксис). Например, если мы хотим чтобы макрос "my type" формировал класс с дополнительным методом "GetTypeName", то можем написать следующее:

usung Nemerle.Compiler;

macro class MyCoolSyntax
{
  [Extends(CoreMacros.TypeDeclaration)]
  macro MyType : PDeclarationBase
    syntax "my" "type" name "{" memrers "}"
    where  name = Identifier, memrers = Member*;
  {
    def getTypeNameMethod =
      <[ class $name
         public GetTypeName() : string
         {
           $(name.ToString())
         }
      ]>;

    newMembers = getTypeNameMethod :: memrers; // :: - операция конкатенации списков.

    <[ class $name
       {
         ..$newMembers // генерируем список членов содержащий распарсеные члены и метод GetTypeName.
       }
    ]> // это выражение возвращается макросом
  }
}

В итоге мы получим класс содержащий как члены распарсеные из исходников, так и сгенерированные в рамках макроса.
Вот как будет выглядеть пример использования такого макроса:

using syntax MyCoolSyntax;

my type MyCoolType
{
  public Field : string = "MyCoolType";
}

def x = MyCoolType();

Assert.AreEquals(x.GetTypeName(), x.Field);

_>Возможно ли использование семантических параметров в секции "where"?

Нет. Но это не проблема. Выше я все объяснил.

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

Что могу сказать. Круто!
Спасибо за неплохой краткий экскурс по языку в плане макросов.
Есть много интересного, но как-то мутновато с макросами, какие-то они специфические. Общего стержня(скелета) не вижу, как-то размазано. Для меня.
Так что, конкретных советов/замечаний по макросам дать не могу.
Как возможный потребитель могу сказать разработчикам — сделайте так, чтобы было красиво.

[offtop]
Но форумом, все равно, ошибся, здесь точно не помогут.
Пишу мало, пишу по возможности как аноним. Читаю регулярно. На рсдн оценки в 50% случаев получают за оффтоп (инфа 100%). Тем самым стимулируют оффтоп.
[/offtop]

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

_>Есть много интересного, но как-то мутновато с макросами, какие-то они специфические. Общего стержня(скелета) не вижу, как-то размазано. Для меня.

Печально. Доработал статью о макросах. Надеюсь, что стало понятнее.

_>Как возможный потребитель могу сказать разработчикам — сделайте так, чтобы было красиво.

Делаем.

_>[offtop]
_>Но форумом, все равно, ошибся, здесь точно не помогут.
_>Пишу мало, пишу по возможности как аноним. Читаю регулярно. На рсдн оценки в 50% случаев получают за оффтоп (инфа 100%). Тем самым стимулируют оффтоп.
_>[/offtop]

Текущий синтаксис подсказан одни из посетителей форума. Мы его конечно додумал, но основная фишка — использование "where" для ассоциации грамматики с именами параметров подсказали на форуме RSDN.

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

VD>Доработал статью о макросах

Очередная порция вопросов.
1. Не очень понятна необходимость указания типа (macro name: type). Судя по мощному выводу типов немерла, это избыточно, тк тип можно вывести на основании синтаксиса и "where", и/или выражению в секции "expr".
2. Незначительная (минорная) придирка в одном месте "when" в другом месте "where"
3. По мне, приоритеты в таком виде внесут больший хаос, чем приоритет на основании порядка объявления. Читать и понимать заранее упорядоченный текст намного проще, чем искать приоритеты по всему тексту.

[offtop]
_>Есть много интересного, но как-то мутновато с макросами, какие-то они специфические. Общего стержня(скелета) не вижу, как-то размазано. Для меня.
VD>Печально. Доработал статью о макросах. Надеюсь, что стало понятнее.

Я ненавижу макросы, особенно сложные. Переиспользуемость таких макросов очень низкая, и в основном не выходит за пределы понимания одного двух разработчиков. (Инфа 100% и вообще то я метр-82, а не метр-20).
То что в немерл макросы могут быть самостоятельным языком, который неплохо формализован как "peg с семантикой" это круто для человека, который часто встречается со всякими дсл. Плохо то что макросы это не "peg c семантикой" и способ расширения немерл и ничего больше. На основании этого у меня срабатывает стереотип с макросами Си — удобно на уровне объявления мин/мах, но не надо на них рекурсивные алгоритмы строить. Не для этого он придуман.
Вообщем, полезный эффект от таких макросов максимум 20% экономии кода, но под большим вопросом понимание этого кода другими разработчиками. (Как уже говорилось — инфа 100%).
[/offtop]

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

VD>Печально. Доработал статью о макросах. Надеюсь, что стало понятнее.


Не очень понятно какие приоритеты имеются ввиду. Приоритеты раскрытия или приоритеты списка выбора грамматики в точках расширения?

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

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

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

P>>Каким образом указать, что я хочу подключиться к такой-то точке расширения?
P>>и как определить точку расширения в моём макросе?

VD>Это пока что открытые вопросы. Вольфхаунд сейчас работает над расширяемосью. Его работа может повлиять на синтаксис.
VD>

VD>[Extensible]
VD>macro TypeDeclaration : PDeclarationBase
VD>  syntax typeDeclaration
VD>  where  typeDeclaration = Alias / Class / Interface / Struct / Variant 
VD>                         / VariantOption / Delegate / Enum / Expr /  / Error;
VD>{
VD>  typeDeclaration
VD>}
VD>

может эдак:?

macro TypeDeclaration : PDeclarationBase
  syntax typeDeclaration
  where  
    [Extensible] typeDeclaration = Alias / Class / Interface / Struct / Variant 
                                 / VariantOption / Delegate / Enum / Expr /  / Error;
{
  typeDeclaration
}

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

P>может эдак:?
P>

P>macro TypeDeclaration : PDeclarationBase
P>  syntax typeDeclaration
P>  where  
P>    [Extensible] typeDeclaration = Alias / Class / Interface / Struct / Variant 
P>                                 / VariantOption / Delegate / Enum / Expr /  / Error;
P>{
P>  typeDeclaration
P>}
P>

Зачем?

И что делать, если макрос имеет более одного параметра?

Расширяемым является весь макрос, а не его параметры.

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

А что означает префикс P у классов типа PTypeDeclaration?