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

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

A>>Разница есть даже между двумя Запорожцами.
A>>Вопрос насколько она принципиальна.
A>>Между Запорожцем и Бугурти (к стати, что это?) принципиальной разницы нет.
VE>Бугатти.
A>>Метро всё равно быстрее их обоих.
A>>А мне надо ехать.

VE>Ну дак метро ещё не построили по твоим же словам. Получается, чёрт с ним с Бугатти, я и на запоре покатаюсь?

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

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

PS. У меня даже Запорожца нет. Предпочел деньги потратить на квартиру.

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

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

H>>Я посмотрел внимательно. Я просто знаю, что sizeof можно вычислить в компайлтайме лишь для примитивных типов (int, double...). Попробуй в свой пример вместо int подставить GCHandle.

V>Э нет, ты не туда смотришь. Я поля из целевых структур храню, а не сами структуры как "черные ящики". Согласен, что тут есть к чему придраться, но для типов из этой же сборки такой подход работает.

"Туда" я тоже смотрел Посему резюмирую:

1) работает лишь для структур из того же компилируемого модуля,
2) работает без наследования,
3) затруднено использование из C#.

Я считаю что этот слишком специфический случай, лучше поддержать макробиблиотекой и активными паттернами.

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

H>>DLR — нет. Но он не особенно востребован.

A>Зря ты так. Cейчас изучаю ASP.Net MVC 3 — там без этого никак

А я на нем (ASP.NET MVC 3) код боевой пишу. Вполне обходимся без этой нетипизированной мерзости.

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

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

H>>>DLR — нет. Но он не особенно востребован.

A>>Зря ты так. Cейчас изучаю ASP.Net MVC 3 — там без этого никак

H>А я на нем (ASP.NET MVC 3) код боевой пишу. Вполне обходимся без этой нетипизированной мерзости.

Можешь ссылку кинуть?

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

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

D>В скале можно на этапе компиляции, хотя со строковыми литералами там беда.

Ммм, а то, что второй аргумент больше первого в скале можно?

VE>>В этом контексте
VE>>

D>>>Демагогия detected. Система типов именно что даёт математически доказанные гарантии.

VE>>звучит как-то нелепо.

D>Ну нелепо, так нелепо. Пишите на динамике, мне же лучше.

Зачем? Мне нравится статика, но это не повод молоть чушь.

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

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

D>Был здесь несколько лет назад некий Роман Дубров, доказывал мне с пеной у рта, что на PHP можно написать всё что угодно, и что memcached является частью платформы PHP, и что сериализация данных при его использовании не выполняется. Много ли этого самого "чего угодно" он написал, мне неведомо. Ну а я тоже дурак — зачем мне его разубеждать? Больше ламеров — ценнее моя квалификация. Адью.

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

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

H>Стопицот строк бессмысленного и по сути ненужного кода хэлперов супротив оригинальных 100?

Дык, в оригинальном само описание типов узлов не приведено, а без них эти 100 не работают. Т.е. это за рассматриваемым кодом, и я тоже привел код, который "за". И всего +10 строк кода хелперов, посчитай внимательнее.

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

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

A>Ну то что Ela вещь в себе ты согласен?

Не больше чем другие функциональные языки

A>Сначала глянул — вау, зашибись, а потом подумал — как его использовать?

Для чего использовать? Если для ембединга, то так и так лучше свое АПИ отдельно описать.

A>По сути текст на входе — текст на выходе. Можно и так вообще-то, но если что-то посложнее строки текста — начинаются проблемы. Вот и предлагаю — сделай поддержку xml или json — будет проще объекты серелизовать.

Тут я не понял. Можно поконкретнее? Глобальная задача "интеропа" решается сложно и криво, но вот конкретные задачи решатся могут легко и просто. Скажем, автоматически транслировать дотнетовый класс в запись Ela, и делать обратный маппинг — не слишком сложная задача.
Наконец это, все типы Ela вполне юзабельны из того же C#

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

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

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

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

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

Завелась шарманка... Оказывается локальный байндинг имён — это killer feature, надо мужикам с Прологом рассказать, что они, оказывается, на острие прогресса. Влад, как ты думаешь, почему я упустил это из внимания?

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

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

Это почему это? Допущение для иллюстрации, не более того. В реальности код может выглядеть примерно так:

if (match(rule, Rule(Rule::Not, Rule(Rule::Not)))) ...

Что с помощью инлайновых функций несложно упрощается до искомого:

if (match(rule, Not(Not())))) ...

Можно помудрить и с привязкой переменных, получится что-то в этом роде:

if (match(rule, Not(Not, &subRule))) ...

То есть в subRule (скорее всего, это будет какой-нибудь smart-указатель) попадёт результат унификации, сиречь, анализа, выполняемого функцией match. Термин "унификация" употреблён из-за схожести процесса с прологовской унификацией.

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

Как минимум, они интересны тебе, раз ты продолжаешь их обсуждать.

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

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

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

Так он тривиальней некуда, хотя зависит от реализации самого Rule. Вот из-за того, что мне лень всё это раскручивать, я и не привожу код match.

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

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

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

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

ГВ>>Спасибо за перевод, но это мне понятно.
VD>Очевидно же, что не понятно. Или надо констатировать факт — ты обманываешь намеренно.

Кого обманываю и в чём?

ГВ>>Конечно, не гарантируется. Только кто тебе сказал, что по отношению к такому примеру цикл заметно ухудшит код?
VD>Мне говорить не надо. Я это на своей шкуре проходил. Это и замедление, и возможность вылететь по переполнению стека.

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

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

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

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

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

ГВ>>

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

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

Чтобы показать, где именно будет стоять continue в этом коде.

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

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

VD>Контролируется, что в операторе match перехвачены все случаи, а не то что в коде присутствует перемножение всех сочетаний. [...]

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

VD>Таким образом верхние паттерны (например, Not(Not(rule))) распознаю частные случаи, а нижние (например, Not(rule)) более общие.
VD>В ПМ важен порядок. Паттерны идущие выше более приоритеные. Если они сопоставились, то нижние уже не проверяются.

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

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

Ценой распыления аналитического кода по всем классам? Ну, я не спорю, субъект с тяжёлым синдромом ООП головного мозга способен и на такое ради "гарантий". Только зачем болезнь выдавать за правило?

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

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

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

Ты понимаешь, в чём проблема, я переболел парадигмами и прочими идеологиями уже довольно давно. Поэтому то, о чём ты говоришь, мне очевидно, но очевидно ещё и то, что сейчас я (и не только я) без веских причин так не сделаю, чтобы там ни тарахтели разнообразные ООП-пуристы и прочие, сдвинутые на спасении мира посредством чистоты парадигмы. Честно, мне плевать, как код реализации проецируется на некий идеал, взятый из той или иной химеры (aka парадигмы), я руководствуюсь вполне локальными соображениями.

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

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

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

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

Разницу между иллюстрацией и фрагментом рабочего кода объяснять нужно?

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

Я же говорю, что переживаниям "твоей шкуры" я доверяю чуть менее, чем никак. Ты теперь сам прекрасно подтверждаешь мои размышления. Поищи в Исходниках по ключевому слову "Делегаты на C++", там даже твои комментарии имеются. Лаялись, кстати, знатно. Что характерно, с того момента ты, если я ничего не путаю, уже изменил свою оценку значения делегатов, как таковых. А в C++ появились лямбды.

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

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

Я? Да, пожалуй, что не могу.

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


A>был бы хороший алгоритм, а реализовать его можно хоть на хинди. Язык не важен.

Угу, мне вот тоже сферические алгоритмы нравится писать, две недели работы в результате 200 строк кода на Си.
Жаль такая работа очень редко встречается, в остальных случаях чем язык выразительней тем лучше быстрее и
качественней работа.

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

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

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

A>Метро всё равно быстрее их обоих.

Сам придумал, сам не знаешь?

A>Моё утверждение просто как палка:
A>был бы хороший алгоритм, а реализовать его можно хоть на хинди. Язык не важен.
A>Вот с этим спорь.

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

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

A>Ну то что Ela вещь в себе ты согласен? Сначала глянул — вау, зашибись, а потом подумал — как его использовать?
A>По сути текст на входе — текст на выходе. Можно и так вообще-то, но если что-то посложнее строки текста — начинаются проблемы. Вот и предлагаю — сделай поддержку xml или json — будет проще объекты серелизовать.

Ну вот, например, "концепт" универсальной обверточки, через которую в Ela можно скормить любой объект:

public sealed class ElaWrapper<T> : ElaObject
{
    private readonly T obj;

    public ElaWrapper(T obj)
    {
        this.obj = obj;
    }

    protected override ElaValue GetField(string field)
    {
        var pi = typeof(T).GetProperty(field);
        return ElaValue.FromObject(pi.GetValue(obj, null));
    }
}

Теперь ты можешь делать так:

class MyType {
  public int value { get; set; }
}

var elaObj = new ElaWrapper<MyType>(new MyType());

и в Ela будет доступно:

elaObj.value

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

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

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

H>>>>DLR — нет. Но он не особенно востребован.

A>>>Зря ты так. Cейчас изучаю ASP.Net MVC 3 — там без этого никак

H>>А я на нем (ASP.NET MVC 3) код боевой пишу. Вполне обходимся без этой нетипизированной мерзости.

A>Можешь ссылку кинуть?

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

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

A>Пока писал подумалось.
A>Есть ли Ela поддержка xml?

В библиотеке пока нет. Можно добавить. Не хочешь попробовать?

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

Если это только для интеропа, то это — оверкил. Все можно гораздо проще.

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

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

Лишние подстановки в традиционных грамматиках — это лишние вызовы ф-ии перебора, либо сдвига-свертки. Поэтому правила обычно оптимизируют, "раскрывают скобки". Всего вашего кода не видел, но эта оптимизация And(And(rule)) в приведенном файле очень похожа именно на нивелирование избыточной глубины графа выражений.

Или ты не понял смысла фразы о "лишних скобках"?

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

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

WH>И я не вижу ни одной причины написать его иначе.

Значит, ни тестов на него писаться ни поддерживаться другими людьми этот код не будет. Это мусор, называя вещи своими именами. То самое "первое приближение", результат эксперимента, и т.д., требующее рефакторинга перед завершением работы над этим участком. Хотя, вот тут уже спотыкаемся об ограничения на раскрутку хвостовой рекурсии. И если это требование принципиально, то декомпозировать можно будет не все.

V>>Смотреть надо. Посетитель тоже тормоз порядочный, хоть и быстрее обычно на порядок, чем развесистый ПМ.
WH>Лол.
WH>Учитывая что ПМ очень даже может тупо по таблицам работать...

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

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

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

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

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

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

A>>Можешь ссылку кинуть?

H>В самом Nemerle можно макрос написать для генерирования вьюх, (гдето даже был). А в C# приходится руками модели прописывать.

А с этого места поподробней, пожалуйста

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

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

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

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

Спорный аргумент о необходимости! Я уверен многие обладают знаниями,которые так и не были востребованы

VD>А до тех пор все эти языки для тебя будут непонятными хреновинвами.

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

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

A>>>Можешь ссылку кинуть?

H>>В самом Nemerle можно макрос написать для генерирования вьюх, (гдето даже был). А в C# приходится руками модели прописывать.

A>А с этого места поподробней, пожалуйста

Для генерирования моделей (я там оговорился) есть макрос в составе замороженного NRails проекта.

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

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

H>>>DLR — нет. Но он не особенно востребован.

A>>Зря ты так. Cейчас изучаю ASP.Net MVC 3 — там без этого никак

H>А я на нем (ASP.NET MVC 3) код боевой пишу. Вполне обходимся без этой нетипизированной мерзости.

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