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

ГВ>

static const RulePattern NotNotRulePattern = Not(Not());
ГВ>...
ГВ>else if (match(rule, NotNotRulePattern)) ...
ГВ>

ГВ>Какой именно тип должен быть указан в качестве RulePattern прямо сейчас сказать не могу.

Никакой. В таком виде ты код не перепишешь. Пример того как это можно сделать показал vdimas. Но в его варианте тоже проблем выше крыши. Так что в реальной жизни люди реализуют паттерн посетитель и дальше пишут много ифов. Кор разрастается как раз где-то в 10 раз. И чем сложнее паттерны, тем более объемным получается аналог на языке без ПМ. Очень скоро объем кода становится таким, что управлять им становится сложно.

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

FR>Можно, но как замена скриптам не очень удобно, типы приходится объявлять, шума больше. Вот динамический жестко функциональный язык, притом не сильно специализированный как эрланг не помешал бы. Вот за pure я слежу, и пока как-то не получилось посмотреть то что Воронков ваяет.

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

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

VD>Хочется собрать статистику (мнения) по поводу что останавливает людей от изучения новых языков.
Отсутствие практической необходимости. Имеющегося знания asm,C,Java,JavaScript,HTML,SQL достаточно для решения любых задач, которые у меня появляются или могут возникнуть. Ради интереса смотрел на Scala, haskell, C#, но в этом всем нет никакого смысла. Может быть, изучил бы Ceylon, когда под него будет IDE.

VD>Так же интересно что останавливает от применения языков. Насколько часто бывает так, что язык вы изучили, а использовать его не можете?
Аналогично — нет практической необходимости.

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

ГВ>Не, этот код я полностью не могу прочесть, потому что смутно представляю себе постановку задачи. ПМ, язык — это всё шелуха. Кстати, спасибо, что объяснил, что именно и зачем тут оптимизируется.

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

VD>>Ген. Не моли чушь просто от того, что ты не понимашь написанного. Ну это же бред.

ГВ>А... Да, есть ошибочка.

Это не ошибочка. Это полное непонимание. Оно не мудренно. ПМ — это действительно другой подход к программированию. Но я тебе уверяю, что освоить его полезно просто для собственного развития.

ГВ>Вызов optimizie нужно было записать примерно так: optimize(And(r.Location, rule.r.r), чтобы показать, что новый узел формируется из вложенного. Но это простительная неточность в данном случае.

Ага. Это простительная. Это — опечатка. А вот это "if (match(rule, Not(Not()))" полная чуешь.

ГВ>Я же полностью рабочий код не собирался делать.

А кому интересны не работающие выдумки? Я тогда могу тоже код представить: Done! и заявить, что он решает данную задачу.

ГВ>Кстати, Not(Not()) может быть заменён на статическую константу:

ГВ>

static const NotNotRulePattern = Not(Not());
ГВ>...
ГВ>else if (match(rule, NotNotRulePattern)) ...
ГВ>

Ну, то есть ты перемещаешь код проверки объекта в match. А что тогда ее код не приводишь?

Кроме того ты не понял важной фишки ПМ. ПМ не только распознает паттерн, но и производит декомпозицию структуры данных.
Паттерн:

| Not(Not(rule)) => ... rule ...

означает выполнить код "... rule ..." в случае если сопоставляемый объект это экземпляр типа None у которого поле rule яляется так же экземпляром типа None, и если этот паттерн распознался, то связать с полем rule вложенного типа локальное имя rule. В коде обработчика (том что идет за =>) в rule будет находиться ссылка на поле вложенного типа. Кроме того тип поля rule Rule (а это базовый тип для Not и остальных правил), так что ПМ за одно осуществляет проверку типов.

ГВ>Спасибо за перевод, но это мне понятно.

Очевидно же, что не понятно. Или надо констатировать факт — ты обманываешь намеренно.

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

Мне говорить не надо. Я это на своей шкуре проходил. Это и замедление, и возможность вылететь по переполнению стека.

ГВ>Цикл тут один, подразумевается он в любом случае, хотя бы в виде tail-оптимизированной рекурсии через ПМ, так что, на "понимаемость" кода его введение повлияет слабо.

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

ГВ>Да и управляться он, пожалуй, будет лучше.



ГВ>Иными словами, приведённый фрагмент будет выглядеть где-то так:

ГВ>

else if (match(rule, Not(Not())) { rule = And(r.Location, rule); continue; }

Это бред, который даже не скомпилируется. Зачем повторяться?

VD>>2. Компилятор немерла работает не с объектами, а свариантами. Это позволяет ему контролировать, что match-и обрабатывают все возможные сочетания. В твоем случае такая проверка невозможна в приципе.

ГВ>Хм. Not(Sequence(rule)) где? Ты ведь говоришь обо всех возможных сочетаниях, нет? Кстати, сочетания какой длины гарантированно контролируются?

Контролируется, что в операторе match перехвачены все случаи, а не то что в коде присутствует перемножение всех сочетаний. В частности гарантируется, что все случаи применения Not и And обработаны так как в конце:

        | Not(Not(rule))                => optimize(Rule.And(r.Location, rule))
        | And(Not(rule))                => optimize(Rule.Not(r.Location, rule))
        | Not(And(rule))                => optimize(Rule.Not(r.Location, rule))
        | And(And(rule))                => optimize(Rule.And(r.Location, rule))
        | Not(rule)                     => Rule.Not(r.Location, optimize(rule))
        | And(rule)                     => Rule.And(r.Location, optimize(rule))

идут два паттерна сопоставляемые с Not и And имеющими любые параметры. Образец And(rule) — это образец-конструтор. Он описывает объект в терминах его создания через конструктор. "rule" соответствует параметру конструктора. Этот паттерн связывает значение поля rule с локальной переменной с именем rule. При этом в rule может быть любой объект типа Rule. Rule — это вариантный тип (АлгТД). Вот его описание. Из описания не трудно понять, что поля rule в Not и And — это рекурсивные ссылки на Rule.

Таким образом верхние паттерны (например, Not(Not(rule))) распознаю частные случаи, а нижние (например, Not(rule)) более общие.

В ПМ важен порядок. Паттерны идущие выше более приоритеные. Если они сопоставились, то нижние уже не проверяются.

VD>>Так что описанная выше прямая трансляция является плохим стилем. Стало быть ее, по уму, нужно заменить на использование паттерна посетитель. Но как только ты это сделашь распознование вложенных паттернов (Not вложенный в Not, как в данном примере) превратится в мучение. Кода станет уже не в 5, а в 10-20 раз больше.

ГВ>Влад, ты когда с самим собой разговариваешь, клавиатуру в сторону отодвигай. При чём тут паттерн "посетитель"?

При том, что он описывает список веток которые нужно посещать и как и ПМ гарантирует, что ты не забудешь посетить их все.

ГВ>То есть я понимаю, каким боком его тут можно привинтить, но это как тебе сказать... Нечто вроде метода показать наихудший из возможных способов реализации. Здесь самая обыкновенная трансформация дерева структур, даже ОО-стиль особо-то впихивать некуда.

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

Если тебе это не очевидно, я не виноват.

Вариант с МП обладает всеми теми же достоинствами плюс:
1. Намного более краткий.
2. Позволяет легко обрабатывать сложные случаи (вложенные паттерны).

В приведенном примере вложенность небольшая (2). Но она не ограничена. И чем сложнее анализ, тем полезнее становится ПМ.

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

ГВ>Конечно, не рабочий, я и не пытался делать его рабочим. Я тебе что, полный PEG-парсер буду переписывать?

Ну, а что обсуждать набор символов нечего не имеющий с реальным кодом?

ГВ>Не, Влад, эпопею с делегатами я повторять не буду — одного раза мне хватило.

Я не слышал про эпопею с делегатами, но если там ты приводил такой же бред вместо года, то понятно что ты "победил" в том споре. Ведь всегда можно написать краткий и понятный, но неправильный код.

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

Ты? Да, пожалуй.

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

___>И еще отсортирован список по алфавиту а не по мощности языка. Это ж просто безобразие.
___>Чтобы ласкающее взор имя прочесть некоторым приходится аж до секции N скролить.
___>Скролишь и думаешь — а вдруг убрали. Инфаркт можно получить однако.

Типа пошутил? Петросян, блин.

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

ВВ>А я как раз и ваяю динамический и жестко функциональный. И фидбек бы мне не помешал

Ela не помещал бы interop, то что ты называешь биндингами.
Ela ты в статьях сравниваешь с Javascript, но он может обращаться к Com-объектам, например, а Ela нет Твои предложения делать обертки для каждого .Net класса выглядят не очень.

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

A>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>А я как раз и ваяю динамический и жестко функциональный. И фидбек бы мне не помешал

A>Ela не помещал бы interop, то что ты называешь биндингами.
A>Ela ты в статьях сравниваешь с Javascript, но он может обращаться к Com-объектам, например, а Ela нет Твои предложения делать обертки для каждого .Net класса выглядят не очень.

Пока писал подумалось.
Есть ли Ela поддержка xml?
Передаем на вход сериализованный объект, Ela c ним что-то делает и отдает сериализованный объект наружу.

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

VE>Плохо переводишь. Неаккуратно. Можно как-нибудь так:
VE>

VE>match (r, types(typeof(Not), typeof(Not)), rule => ... ));
VE>

VE>С учётом написания not = typeof(Not) и другого boilerplate в 2-3 строки код станет не сильно хуже изначальной лапши.
VE>Частные случаи, которые под этот вариант не подпадут, уж никак 20-кратного отставания не принесут.

Это очередной говнокод. В добавок еще и дико медленный.

Всем кто хочет эмулировать МП в рантайме — сливового геморрой!

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

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

C>>>а не все ли равно на чем писать?
VD>>Нет конечно. Иначе все бы писали на ассемблерах или хотя бы на Фортране 77.
C>я не это имел ввиду.

Именно это ты и имел в виду. Только ты почему-то видишь разницу между фортраном и С++ (например), но не видишь разницу между скажем С++ и скажем Скалой.

C>>>а если так, то зачем учить очередной язык пока он не понадобился?
VD>>А как ты поймешь что что-то тебе нужно, если ты даже не знаешь что там внутри и что это тебе может дать?
C>А для того чтобы понять что там внутри не надо язык изучать, обычно достаточно прочитать какой нибуть обзор или полистать домашнюю страничку.

Не недостаточно. Чтобы понять новое его нужно пробовать. Ну, то есть в принципе можно понимать возможности языка просто прочитав про него, но при этом все концепции этого языка должны быть известны. Например, зная Немерле или ОКамл можно прочитать книгу об F# и понять что из себя представляет этот язык. Но зная С++ или C# недостаточно прочитать что-то про F#, Немерле или ОКамл. Это просто бесполезно.

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

Вот модель радио тут не причем. Ну, разве что если сравнивать гетеродинный приемник метрового диапазона и современные стереофонический FM-риемник. Но и это не корректное сравнение, так как кроме повышения качества тут ничего не будет. А в случае языков разница приципиальная. С языком ты получаешь новые концепции. После изучения которых ты сможешь мыслить другими категориями. Это именно как сменить звук на картинку со звуком.

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

G>То есть единого источника к которому можно обратиться за справкой таки нет.

http://nemerle.org на английском. rsdn на русском.

G>Ну конечно, отличие только в том что мусора в форуме на несколько порядков больше и найти информацию там труднее.

Особо ценная информация вынесена в Q&A. Ну, а если язык интересен, то вряд ли форум будет для тебя мусором.

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

VD>>Это ты тоже придумал. На практике по этим курсам учат студентов в польском институте.
G>Я так понимаю что обучали те, кто писал nemerle. Ксттаи не поленись и попробуй прощелкать все ссылки, половина ведут вникуда.

Еще раз. Не настраивай себя исходно негативно. Ты C# знаешь?

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

M>Читаю некоторый обзор, придумываю задачу, которая должна соответствовать языку и потом начинаю на нем писать решение. В ощущения входит: (1) легкость быстрого старта (2) тормоза (3) хорошая диагностика ошибок (4) быстрый поиск по документации ответов на вопросы (5) бенефиты перед уже известными языками.

Пожалуй двигательный подход. Интересно почему такой ответ только одни?

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

M>>Читаю некоторый обзор, придумываю задачу, которая должна соответствовать языку и потом начинаю на нем писать решение.
VD>Интересно почему такой ответ только одни?

Потому что как правило "придумать себе задачу" == "высосать её из пальца". "Когда результат никому не нужен, трудно процесс сделать захватывающим." (c) МихМих.

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

M>>Читаю некоторый обзор, придумываю задачу, которая должна соответствовать языку и потом начинаю на нем писать решение. В ощущения входит: (1) легкость быстрого старта (2) тормоза (3) хорошая диагностика ошибок (4) быстрый поиск по документации ответов на вопросы (5) бенефиты перед уже известными языками.
VD>Пожалуй двигательный подход. Интересно почему такой ответ только одни?

Потому что мало кто учит языки по своей воле.

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

VD>Особо ценная информация вынесена в Q&A. Ну, а если язык интересен, то вряд ли форум будет для тебя мусором.

Где можно посмотреть список фич, которые добавились после поляков?

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

A>Ela не помещал бы interop, то что ты называешь биндингами.

Обвертки так или иначе делать придется. Собственно, посмотри на F#. Хочешь писать в функциональном стиле — только через обвертки, без этого имеешь тупые tupled функции, с которыми ничего интересного не сделать.
Так же и тут. Можно сделать интероп, но он будет слабо юзабелен. Параметры аргументов в функциях неправильные, первым аргументом для большинства будет какой-то this, который непонятно вообще что за зверь и пр. Зачем нужен такой интероп? А времени на него придется убить немало, одна перегрузка чего стоит.

A>Ela ты в статьях сравниваешь с Javascript, но он может обращаться к Com-объектам, например, а Ela нет Твои предложения делать обертки для каждого .Net класса выглядят не очень.

По факту даже не так. Надо делать не обвертки для каждого класса — если бы было так просто, то этот процесс легко бы автоматизировался — а переводить .NET API в более функциональное. Императивный код и ОО-код на Ela писать в принципе можно, но это неудобно.

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

V>Дык, ссылочные поля могут как раз могут перекрывать друг друга, и GC отлично работает. Эти ссылочные поля нельзя перекрывать нессылочными.

Это да. Но это не декларируется. Стало быть это будет закладывание на особенности реализации. Вот перепишут ЖЦ и что будет тогда?

V>Только ты GC все-равно не поломаешь,

Я ломал. Во втором рантайме по крайней мере. Достаточно добавить атрибуты задающий отстпы полей в структуре и получаешь вылет ЖЦ. Там тупой С++-ный код. Я описывал примерный алгоритм здесь

Автор(ы): Чистяков Влад (VladD2)
Дата: 14.06.2006
Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройчтва GC в .NET Framework.

.

V>среда исполнения просто не загрузит такую сборку.

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

V>Я же не зря упомянул процесс "упаковки". Должен быть внутри адресного поля объекта некий "пул" под объединение нессылочных и отдельно ссылочных полей.

Это все оверкил. Еще о вариантах в которых все поля — вэшлью-типы можно подумать. А если появляются ссылочные поля, то овчинка просто не стоит выделки.

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

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

V>Вот простеший пример, я поля вручную раскидал, ссылочные перекрывают ссылочные, нессылочные перекрывают нессылочные:
V>Отлично вызываются все финализаторы. Запусти проверь. Заметь, я поставил не просто два экземпляра похожих типов, но один из них завернул в коллекцию List<>.

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

Уже четрые поля размером по 32 бита делают делаю структуру невыгодной с точки зрения производительности.

Получается, что подобная оптимизация будет распространяться на очень малое количество применений.

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

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

Это потому что у тебя тесты не реальный. 10 байт это по сути два поля. Причем вариант не должен содержать вхождения только вэлью-полей и только ссылочных.

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

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

V> Понятное дело, что компилятор должен иметь верхний предел размера объекта после операции всех упаковок для принятия решения о технике реализации конкретного АлгТД.

Ладно. Время затраченное на этот разговор уже превысило разумное.

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


VD>>Смысла нет. На копировании в итоге проиграешь. Разве что ли для вариантов с одним полем. Но это как раз редкость.

V>Где-то на копировании проиграешь, а где-то за счет -1 уровню косвенности прилично выиграешь. Про верхний предел в размере я уже сказал и его было бы неплохо поискать через эксперименты. Или же явно дать программисту возможность управлять этим, MS же не постеснялась ввести ключевое слово struct. Потому как не только размер имеет значение, но и сценарии использования. Почему бы не ввести некое "variant value"?

Потому что это лишняя сущность не дающая ничего кроме производительности.

Пойми, если нужно создать очень быстырй код, то в нем просто не место ни вариантам, ни объектам, ни даже полиморфизму. Погляди на код который порождает тот же PegGrammar. Это ужасный код в стиле С времен К&Р. Но он действительно быстр!

У немерла свой путь. Его путь — это очень высокий уровень при статическйо типизации с возможность, если надо, сгенерировать очень быстрый код.

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

Описанный код оптимизации правил работает именно во время компиляции. Более того он может работать только когда компилируется оптимизированная релиз-версия программы. По сему он отнимает время только во время компиляции. К тому же он довольно быстр. Объектная модель грамматики не так уж велика. Это какая-то жалкая сотня правил (даже десяток тысяч объектов не затормозит существенно его работу).

VD>>Многие варианты рекурсивны и имеют по 3 и более полей. Делать разную семантику для одной и той же сущности?

V>Фишка в том, что даже рекурсивные АлгТД вполне выполнимы по этой технике и во многих простых случаях дают прирост за счет буста наиболее частой операции — получения головы. Почти все алгоритмы смотрят/матчат значение головы, а тут -1 на косвенность. Это не мало.

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

V>Дополнительные оптимизации к этой только плюсуются и никак ей не помешают. Передача небольших типов по значению — это самое естественное в программировании.

Не спорю. Но любая оптимизация — это многоаспектная задача. Просто так предсказать результат практически невозможно. К тому же любая оптимизация не бесплатна. Она неизбежно ухудшит код компилятора.

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

ВВ>Обвертки так или иначе делать придется. Собственно, посмотри на F#. Хочешь писать в функциональном стиле — только через обвертки, без этого имеешь тупые tupled функции, с которыми ничего интересного не сделать.
Это отмазки. Немерле никаких проблем не имеет.
Так что сделать можно.
Нужно только сразу делать как надо.

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

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

A>>Ela не помещал бы interop, то что ты называешь биндингами.

ВВ>Обвертки так или иначе делать придется. Собственно, посмотри на F#. Хочешь писать в функциональном стиле — только через обвертки, без этого имеешь тупые tupled функции, с которыми ничего интересного не сделать.

Так в N вроде без оберток. Или но не функциональный?

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

VD>Не неси пургу. Это трансформация дерева. Причем вынесенная в отдельную функцию (локализованная). Устранять здесь "диспечиризацию" — означает превращать код в говно смешивая разную логику.

Кто-то предложил устранить диспетчеризацию? Перечитай плиз замечания еще раз, бо ты пока не понял, что именно критикуется.


VD>Если ты до этого еще не до рос, то иди работай над собой, а не давай советы вселенского масштаба и вселенской же глупости.

И тебя приятно видеть все в той же боевой форме.

V>>Хе. А если ему Лисп привычен?
VD>Он только название такое знает.

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

V>>А что, обрабатываемые правила могут иметь бесконечную вложенность?

VD>С достаточной чтобы получить переполнение стега.

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


V>>И вопрос на 1000000 баксов: в Немерле хвостовая рекурсия только в рамках одной ф-ии работает?

VD>К сожалению — да.

В принципе, тогда все ясно, половину обсуждения можно сворачивать.

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

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

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

Это понятно, просто сия задача оптимизации сильно привязана к типу узла, и я многократно видел (и сам так же организовывал оптимизацию графов выражений) именно через ее реализацию в теле соответствующего объекта, представляющего узел. Бо задача как бы обязательная при построении графов выражений. Как минимум от лишних скобок (ваше And(And))) всегда избавляются.

Хотя, после пояснения относительно ограничений хвостовой рекурсии в N все вопросы отпадают. Беда, тут нечего обсуждать.
Вот этим стоило заняться в первую очередь. Просто все остальное бросить и заняться этим. Ибо (посмотри чуть со стороны) влияние фичи конкретной реализации компилятора на стиль писания на языке (а компилятор и язык, по идее, не одно и то же, хоть и верно для ваших реалий), это жирный такой минус. Факт: приведенный код сразу же сказал о св-вах компилятора заглянувшему человеку со стороны. Показательно.


VD>Код, кстати, не верный.

Проверь оригинал. Если же речь про Location, я позволил себе опустить подробности.


VD>А что ты будешь делать когда потребуется еще один уровень вложенности? Начнешь типы приводить и вложенные кейсы писать?
VD>Да, и не видно шаблонов! Ты тут ведь недавно про шаблоны говорил. Они же должны дать невероятный эффект.

Я говорил про код Гены и хелперы для синтаксиса.


VD>Очень интересно что ты будешь делать когда придется кроме оптимизации еще каую-то обработку сделать? Бежим по файлам и добавляем новые методы? Посетитель ведь нам не нужен.

Смотреть надо. Посетитель тоже тормоз порядочный, хоть и быстрее обычно на порядок, чем развесистый ПМ. Если не привязываться в AST к виртуальным вызовам и некоему "базовому интерфейсу", который не облокотился при наличии структурной типизации на шаблонах в С++, то конечно! бежать по файлам и добавлять легковесные операции в специализированные легковесные объекты, всё в инлайне и без виртуальных вызовов.

В общем, в плюсах свои интересные плюшки есть и их охотно пользуют.


VD>А где Команда? Ты ведь еще этот паттерн упоминал.

"Стратегию", а не "Команду". и не для матча, а для одной из операций во время пробега по списку.


VD>Если приглядеться, то несложно заметить, что код твой стал полным говном, так как контроль компилятора утрачен. Обрати внимание на то что МП контролирует наличие всех возможных пересечений в match.

Ты уж договаривай. Ваш матч так же позволяет задать дефолтное поведение, чтобы не описывать все варианты, если оно не надо. С++ тоже не позволит не вернуть значение, если его положено вернуть, поэтому там стоит default. Насчет лучшей типизированности решения на матчах я и не спорю, бо лучшая типизированность всегда лучше.

А замечания были о следующем, напомню:
— диспатчинг и обработка свалены в кучу, например, приведенные мной ф-ии не были завязаны даже на optimize, т.е. на ограничения по хвостовой рекурсии, т.е. они просто не нужны в теле этого метода. И их нельзя отдельно протестировать в данном оформлении. А тестировать надо, ведь вы запчасти компилятора пишете, и ошибка вероятна не только в этом коде, а где-то еще в компиляторе, но на этом участке она может просто проявиться.
— утверждения насчет 20 раз экономии строк кода.

Оба вопроса ортогональны друг другу.

VD>Серьзено? Вместо аж трех? Ты привел замену двум строкам кода:
VD>

VD> | Not(Not(rule))                => optimize(Rule.And(r.Location, rule))
VD> | And(Not(rule))                => optimize(Rule.Not(r.Location, rule))
VD>

VD>и то с ошибками.

Внимательнее смотрим:

        | And(Not(rule))                => optimize(Rule.Not(r.Location, rule))
        | And(And(rule))                => optimize(Rule.And(r.Location, rule))
        | And(rule)                     => Rule.And(r.Location, optimize(rule))

VD>В результате вместо двух строк ты получил 7 в сжатом виде.

Нет, я получил вместо N строк кода N+2. Дополнительные строки, связанные с закрывающими скобками, зависят от форматирования.

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

Ровно наоборот. При удачной декомпозиции, любые изменения в ДРУГИХ, не связанных типах узлов, не повлияют на ЭТОТ код.

V>>"Рабочесть" приведенного кода зависит от обвески,

VD>Что за rule тут взялось из неоткуда? А Not(Not()) это что за хрень? Врменные объекты?

Вот, наконец вопросы по существу, хоть и развлекательного плана.

Да, Not(Not()) может быть чем угодно, например, временным объектом, и совсем другим, чем Tag::Not, т.е. специальным как бы "синтаксическим хелпером", он может быть 0-й длины, и служить исключительно целям визуализации диспетчеризации перегрузок сигнатуры match. В общем, в плюсах выбор синтаксиса невелик: это синтаксис вызова ф-ий (оно же вызов конструкторов) + переопределяемые имеющиеся операторы, в том числе operator(). Поэтому, тут возможны минимум три варианта. Один из них приведу ниже.

VD>Короче это бред, а не код. Его не заставить летать даже с помощью волшебной палочки.

С помощью ящика пива на спор гораздо проще.

VD>Не знаю. Покажи, я ознакомлюсь.

Так можно:

template<typename Tail>
struct Cons { Tag::Enum head; Tail tail;};

struct Nil {};

template<typename Tail>
inline bool match(Rule * rule, Cons<Tail> tagList) {
  retun rule && rule->tag() == tagList.head && match(rule->arg(), tagList.tail);
}

inline bool match(Rule * rule, Nil) { return false; }

#define DEFINE_HELPER(xtag) \
template<typename Tail>     \
Tag::Enum xtag(Tail tail = Nil()) { return make_cons(Tag::xtag, tail); } // make_cons() пусть идет как домашнее задание

DEFINE_HELPER(Not); 
DEFINE_HELPER(And); 
DEFINE_HELPER(Choice); 
DEFINE_HELPER(Sequence);

...
// пользуем
if(match(rule, Not(Not()))) { ... }

Самое основное — стремящаяся к нулю вероятность использования в работе.
К сожалению, на просторах СНГ старую недобрую Java требуют гораздо чаще.
Будут идеи — попробую в своих собственных проектах.
К тому же, со временем стал относиться к ЯП просто как к инструменту. Проектирование системы, R&D, постановка цели для меня сейчас вышли на первый план.