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

VD>>Потому что есть три разных случая:
VD>>1. Объявление макроса с явным заданием типа возвращаемого значения.

Z>

Z>macro f(a : Expr, b : Expr) : Expr
Z>{
Z>  <[ $a + $b ]>
Z>}
Z>

Это вообще не в кассу. Речь идет о синтаксических макросах.

VD>>2. Объявление макроса расширяющего другой макрос.

Z>Расширяют не макрос, а синтаксис, список выбора для парсера, где может ожидаться некий тип AST.

Z>

Z>macro f : Expr
Z>syntax "f" "(" $a "," $b ")";
Z>where a : Expr, b : Expr;
Z>{
Z>  <[ $a + $b ]>
Z>}
Z>

Синтаксис расширяется макросом. Короче ты, похоже, не въезжаешь в тему.

VD>>3. Объявление расширяемого макроса.

Z>А нужно ли оно вообще? Если нам нужен TopDeclaration, мы берем все макры с синтаксисом которые возвращают TopDeclaration.

А объявлять его не будем? Это примерно тоже самое, что переменные перед использованием не объявлять. Прикольно, на радость не долгая... до первого копипаста.

Z>Я не могу придумать ситуации, кода нам требуется абстрактный макрос, типа определяем синтаксис, но оставляем на откуп другим сборкам внутренние детали? Ну так надо объяви

Ага. Отличная идея! Тогда уж не будем останавливаться на достигнутом! За одно отменим интерфейсы и полностью абстрактные классы!

Как мы узнаем, что человек вводит новое расширяемое правило, а не просто печатался в имени другого правила?


VD>>>>Еще раз. У нас есть две сущности:
VD>>>>1. Расширяемые макросы — это, по сути, правило грамматики которое не имеет собственного описания и не может иметь тела. Это чисто абстрактная вещь. Она только лишь задает информацию о том, что есть такое правило и его можно расширять.

Z>А зачем эта информация нужна? Если правило где-то используется — оно уже известно, если не используется — нафик оно?

Мы декларируем точку расширения. Точно так же как декларируем интерфейс или переменную. Что тут непонятного?

Z>Расширить пример описания операторов примером функции @::. Чтобы понятно было, что это вообще и как их создавать.

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

Z>Почему не прокатят?

Проблема курицы и яйца. Плюс просто неудобно. Люди будут путаться. Описание приоритетов и ассоциативности должно быть в более явной форме задана. Задать его в этих терминах мы не можем. Группы сил связывания самое близкое приближение.

VD>>Задавать силу связывания относительно других операторов — это плохая идея. Да и столько букв — это тоже лишнее.

Z>Буквы нужны, чтобы люди впервые видящие такой код понимали, что там к чему.

Я не хочу мучиться из-за тех, кто не хочет учиться. К тому же все равно человек с улицы с этим не разберется без обучения. А уж замена операторов на английские слова — это полная дурь. Это уже проходили в Коболе. Идея признана провальной.

Z> А не начинали утверждать, что это жутко сложный птичий язык.

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

Короче, идея литературизации описания мне не нравится. Предлагаю ее закрыть.

Идея выноса описания сил связывания в отдельные подвыражения обсуждается. Может так и поступим. Нужны аргументы за и против.

VD>>Какой на фиг пролог? Нет тут никаких задач.

Z>Чтобы получить числовые приоритеты из кучи условий требуется решить логическое уравнение.

Да ладно! Это задача для бэйсика и школьника . Надо всего лишь создать направленный граф зависимостей, проверить, что в нем нет циклов и тупо пройтись в цикле по нему и назначить значения (вычисляя их иннкремнтом).

Проблема только в том, что все это надо будет делать в рантайме.

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

Z>>Чтобы получить числовые приоритеты из кучи условий требуется решить логическое уравнение.
WH>Нет. Требуется произвести топологическую сортировку.

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

Ты собираешься в ближайшем обозримом будущем дописать реализацию внедрения TDOP в твой генератор парсеров?
Если нет, то я берусь за эту задачу сам.

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

Если ты полностью охладел к задаче, то прошу связаться со мной и помочь мне разобраться с этими вопросами.

Кроме того я так и не понял зачем ты отклонился от описанного тобой же алгоритма. Если на то были реальные причины, то так же хотелось бы их услышать.

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

Z>>Чтобы получить числовые приоритеты из кучи условий требуется решить логическое уравнение.
WH>Нет. Требуется произвести топологическую сортировку.

Блин, ну конечно Видимо я просто сильно хочу пролог.

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

C>Я так понял, : это просто возвращаемое значение. А расширяет именно is. То есть макрос MyMacro : Expr возвращает Expr, но при этом не является расширением Expr-а. Правда, не знаю зачем это

Тогда у меня фича. Функция может возвращать значение, использовать которое нигде нельзя. Правда не знаю зачем это

Вот скажите мне, на кой ляд нужен макрос возвращающий TopDeclaration и не расширяющий список выбора парсера TopDeclaration? На кой ляд макрос расширяющий список выбора TopDeclaration и не возвращающий сущность TopDeclaration? Что с ней может делать парсер, кроме как засунуть в список list[TopDeclaration]?

Если на это нет возражений, пусть мне кто нибудь объяснит, что из TopDecalration является "макросом", а что "его расширением"? Они все равноправные. Я вообще не понимаю смысла терминологии "расширяемый макрос", а "точка расширения" нужна только для того, чтобы запретить расширение где угодно, а разрешить только в расово верных местах. Что никак не вяжется с концепцией максимально расширяемого парсера.

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

VD>А объявлять его не будем? Это примерно тоже самое, что переменные перед использованием не объявлять. Прикольно, на радость не долгая... до первого копипаста.

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

Явное объявление точки расширения нужно только в одном случае. Когда точку мы пишем в одном модуле, сами расширения в другом. Но я не вижу ни одного разумного сценария использования подобной фичи, только вред. Впрочем я не настаиваю, можно сделать так:

abstract macro F : Expr;

Основное не это. Ты так и не показал необходимость is.

Заявления:

Синтаксис расширяется макросом. Короче ты, похоже, не въезжаешь в тему.

В ответ на пример именно синтаксического макроса отбивают желание дискутировать начисто. Ты же по делу ничего не возразил. А разговор перевел в стиль "слепого с глухим".

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

VD>Здравствуйте, Дьяченко Александр, Вы писали:

ДА>>*Про оставшиеся кавычки уже говорили.
ДА>>*Почему в квазицитат-ах то "TypeDeclaration.Class:", то "Class:" используется? Я догадываюсь, но надо или пояснить, или сделать одинаковым.

VD>Исправил.

using Nemerle2.CoreSyntax.TypeDeclaration;
...
match (typeAst)
{
  <[ Class: abstract class MyClass : ..$parents { $members } ]> => ...
  ...

А | перед цитатой не нужна?

Здравствуйте, Дьяченко Александр, Вы писали:

ДА>А | перед цитатой не нужна?

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

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

Z>Явное объявление точки расширения нужно только в одном случае. Когда точку мы пишем в одном модуле, сами расширения в другом.

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

Z>Но я не вижу ни одного разумного сценария использования подобной фичи, только вред.

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

Z>Впрочем я не настаиваю, можно сделать так:
Z>

Z>abstract macro F : Expr;
Z>

А что все это значит то? Это бессмыслица какая-та.

Z>Основное не это. Ты так и не показал необходимость is.

Да я то показал. Но ты игнорируешь. Попробую еще раз (последний) объяснить. Возможно такое объяснение будет более понятно.

Итак, предположим что у нас есть грамматика вида:

Expr = Literal / Parenthesis / Add / Sub / Mul / Div;
Literal = ...;
Parenthesis = ...;
Add = ...;
Sub = ...;
Mul = ...;
Div = ...;

Наша задача, как дизайнеров языка, избавиться от " = Add / Sub / Mul / Div" с тем чтобы можно было расширять список правил входящий в Expr путем добавления нового правила (на самом деле все несколько сложнее, но мы абстрагируемся от сопутствующих проблем).

Наша задача как-то указать у правила, что оно расширяет другое правило. Как это сделать?

WolfHound предложил в PegGrammar использовать для этого конструкцию;
[nemerle]
Add is Expr = ...;
[nemerle]

На мой взгляд вполне себе приемлемые решение.

Теперь нам нужно спроектировать расширяемый мета-компилятор который оперирует не правилами грамматики, а более сложными сущностями — макросами.

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

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

Z>Заявления:
Z>

Z>Синтаксис расширяется макросом. Короче ты, похоже, не въезжаешь в тему.

Z>В ответ на пример именно синтаксического макроса отбивают желание дискутировать начисто.

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

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

Ведь на фантазировать можно что угодно. Но взлетит только план опирающийся на глубоко продуманную модель.

То что я хочу сделать в промышленном качестве еще никто и никогда не делал. Да и в исследованиях рассматривались только отдельные аспекты. Это означает, что задача стоит очень не простая. И малейшая ошибка на уровне планирвоания приведет к неудаче всего проекта.

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

Z>Ты же по делу ничего не возразил. А разговор перевел в стиль "слепого с глухим".

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

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

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

Z>Вот скажите мне, на кой ляд нужен макрос возвращающий TopDeclaration и не расширяющий список выбора парсера TopDeclaration?

Это же элементарно, Ватсон!

Это может быть не синтаксический макрос просто порождающий АСТ класса. Или это может быть часть синтаксиса более сложного макроса. Ну, например, так:

macro Orm : Ast[list[TopDeclaration]]
  syntax "ORM" "{" entities "}";
    where entities = Entity*;
{
  Ast(entities)
}

macro Entity : TopDeclaration
  syntax "entity" name "{" ... "}";
  where ...;
{
  // преобразуем синтаксис энтитей в классы базового языка
}

Итого параметр entities первого макроса имеет тип list[TopDeclaration], но при этом Entity не расширяем грамматику TopDeclaration. Это значит, что мы не сможем описать этити в пространстве имен или в классе, а сможем описать их только внутри конструкции:

ORM
{
  ...
}

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

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

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

Z>>>Чтобы получить числовые приоритеты из кучи условий требуется решить логическое уравнение.
WH>>Нет. Требуется произвести топологическую сортировку.

Z>Блин, ну конечно Видимо я просто сильно хочу пролог.

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

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

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

Для вывода типов нужна специализированная версия.

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