Здравствуйте, Sinclair, Вы писали:
S>4. Анонимные типы. Аналогично анонимным делегатам, помогает избавиться от мусорного кода по декларированию временных структур только для того, чтобы передать данные от одного фрагмента запроса к другому. S>5. Спец.синтаксис для SQL-Like запросов. Совершеннейший сахар; ничего особенного не дает.
S>Из этого списка сходство с возможностями монад имеет только п.4, и то это весьма отдаленное сходство. Если ты так хорошо понимаешь суть сходства Linq и монад, тебе не составит труда кратко обозначить, какие из перечисленных мной возможностей связывают между собой эти понятия. Не отвечая вопросом на вопрос и не ссылаясь на ссылки на цитаты. А?
Тройка замечаний.
1. Все же не анонимные делегаты, а анонимные методы. Это так мелкая придирка. Их почему-то все путают.
2. Анонимные типы — это аналог (кастрированный) кортежей (tuple-ов) и к монадам он отношения не имеет.
3. Булщит зелепил не он, а ЕвилЧилд, а данный товарищь просто решил его поддержать.
По сути же соверешнно согласен. Ребата натрепались, а теперь духу не хватет признаться, что ошиблись.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>как я понимаю, композиция этих extension methods в haskelдВи делалась как раз с помощтю монады.
Не правльно понимаешь. В Хаскель нет понятия объектов. В нем все фукнции являются глобальными. Так что аналогов в нем просто нет. Методы-расширения это всего лишь возможность вызвать статически метод не так:
int x = SomeClass.SomeStaticMethod(someObject, "a");
а так:
int x = someObject.SomeStaticMethod(1, "a");
В Хаскеле пожалуй прямым аналого будет оператор piplene — |>.
BZ> что давало возможность писать императвиный код внутри этого как бы sql-запроса.
Оставь свои домысли. В C# функциональный код писать не просто. А императивный можно писать везде и всегда.
BZ> можежь сравнить это с List monad — она перечисляет все значения в списке и позволет тебе выполнить какие-то вычисления над ними, или отфильтровать их
Это вообще не в кассу. В C# почти все встроенные коллекции позволяют модификацию по месту. Это вообще не проблема. Линк же использует идею итераторов. Собственно итераторы ты уже мог наблюдать здесь
Здравствуйте, lomeo, Вы писали:
L>Я показывал общие свойства.
Ничего ты не показал.
L>Допустим, мы разрабатываем конкретную монаду в C#. Ну, предположим, у нас есть время поизвращаться. Дальше код условный, я на С# не пишу.
Вот с этого надо и начинать было. "С# и занимаюсь гипотетическими рассуждениями...".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Может быть, аналог такого тоже можно изобразить в виде монады на функциональном языке. Но это уже скорее из области доказательства взаимной эквивалентности машины Тьюринга и частично-рекурсивных функций.
Вот именно. Плюс демагогия разводимая на базе этого факта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Но ведь каждый думает по своему, когда решает какую то задачу. Монада — это паттерн, решающий задачу. Допустим, мы идём от него — мы же хотим выяснить связь?
Блин, для особо упертых... Да, паттерн, но паттерн Хаскеля. В ООЯ ему просто нет места. Конечно его даже можно изобразить на ООЯ в которых поддерживаются функциональные объекты, но вот нужны в нем нет, так как есть другие подходы более естесвне6нные для этих языков.
ЗЫ
Так нам будут показаны куски LINQ в которых используются монады?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, palm mute, Вы писали:
PM>Здравствуйте, GlebZ, Вы писали:
GZ>>А почему бы не через continuations? Можно доказать то же самое — но без термина монада. PM>continuations выражаются через монады .
ОК, господа трепачи. Вот вам C#. Монады вы на нем сотворите без проблем, это вы уже тут раз дващцать сказали. Тогда пользуясь истенностью вашего послендего утверждения "continuations выражаются через монады" и реализуйте, плиз, в C# continuations. Лично скажу вам огромное спасибо и поклонись до земли. Ну, а если кода не будет, то будем считать это силивом по полной порогрмме на чем и закончим эту дисскуссию.
ОК?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
...
По-моему, зачательная демонстрация того, что простые и прямые решения лучше чем эмуляция. И не важно ради чего эта эмуляци делается, из соображений совместимости, или в пылу борьбы за чистоту.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
VK>>Теперь пример с использованием исключений и без лишней функциональности, полученный из вышепревиденного примера: M>Красиво и аккуратно.
Но менее фунционально. Ведь пример с исключениями останавливается на превой ошибке. В реальных компиляторах так поступать нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
M> Это у Вадлера он в однобуквенных идентификаторах. Я старался избавиться от них, оставляль только в очевидных случаях типа Add x y
К сожалению не всегда все очевидно m, a, s и т.п. просто сбивают с толка.
VD>>Темболее мне не хочется писать пдобную груду кода. M>Там больше комментариев чем кода.
И все же. У меня еще дел полно, а пенисометрия заранее бессмысленная.
Открою секрет, я обычно пишу пенисометрический код только если он нужен мне где-то еще. Например, в статье. Получается чтл-то вроде продукции двойного назнанчения.
VD>>Прицитпиальных проблем повторить пдобную фигню на Немерле я не вижу. M>Дык их и нету. Причем можно повтороить 1 в 1 буквально. Что я наверное сделаю как будет время.
Имеется в виду без монад. Они здесь лишнии. Это костыли Хаскеля для бопрьбы с отуствием сотсояния и ленивостью.
M>Ок. Давай кратко опишу задачу. Простейший интерпретатор с грамматикой
...
Блин, я хринею. Взял и практически повторил свой исходный пример. на "простейший интерпретатор" это мало похоже. Простейший я уже приводил. Плюс в исходниках Немела есть "сложнеший", т.е. интерпретатор самого Немерла.
Ты бы лучше выделял задачу которую хочешь продемонстрировать на минимальном примере, а не на "простейшем" в твоем понимании. Темболее что Vermicious Knid уже реализовал твой пример. Жаль, что только толку для окружающих в этом всем мало. Ведь конретных проблем вы так и не продемонстировали. А без этого для 99% читателей ваших соощений все это куча закорючек.
Хотя конечно визуально видно, что код на Хаскеле как минимум не короче, и точно более запутан и менее понятен. Что лично меня только укрепляет во мнении, что монады в импертивных языках не нужны, а Хаскелю они нужны как костыли позволющие обхдить чрезмерную чистоту.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Путаешься в монадах? Не используй Хаскель, проблем то.
Я не то что бы путась. Я нелюблю когда трехэтажные навороты применяются на ровном месте. Опять же тот же принцип Оккама. Хороший надо признать принцип, хотя и эмпирический.
Хаскель я тоже не применяю, так как мне не интересны задаче в которых не важна скорость. Незнаю почему. Не српашивай. Просто так выходит, что все чем бы мне не было интересно заниматься требует максимальной производительности для приемлемой работы на современной технике.
VD>> Таких как ты найдутся еденицы, такик как я подавляющее больинство.
L>Спасибо. Для меня это комплимент.
Пожалуйста. Годрись этим. Но практической пользы от этого — 0.
VD>>При выборе языка. При принятии решения возиться с ним или бросить. Да и вообще при принятии решений. Из двух решений всегда надо выбрить более простой и понятное если коенчнь оно подходит. Тут я с тов. Оккамом совершенно согласен.
L>Нет. Из двух решений всегда надо выбирать подходящее.
Так. Извини, но мне надоело принимать в бесполезной словесной переплаке. Ты встал в ряд демагогов. Если будет сказть что-то интересное, то я с удовольствием выслушаю. А смотреть на словесную эквилибристику и контр-аргументацию в стиле "нет не белое, а белое" не не интересно.
Адью.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
VD>>От, блин, а мужики то и не знали. Арабы хрен знает сколько лет назад придумали позиционную систему счисления и пользуются ее. Описываенся она на раз. А у Хаскеля идеологические проблемы. Впроче, как всегда. Вот по этому я и говорию, что это интеллектуальное извращение и самообман. Попытка отгородиться от окружающего мира шорами.
L>И? Каким образом позиционная система счисления позволяет нам записывать перечисление?
Какой бред, а?! Какие перечисления? Перечисление конечно по определению. А числа бесконечны. Это в Хаскеле было принято идиотское решение считать числа перечислением. Вот пусть и решают сами же созданные проблемы. А я лучше у арабов поучусь. Пишу 1 получаю "один". Пишу 1 и еще 1, т.е. 11, получаю "один десяток и один" или "одинащцать". И никаких идеологических проблем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Влад. Для начала нужно понять что такое догмат "чистоты" в особенности со стороны компилятора. Это не Lazy. Lazy — всего лишь одна из оптимизаций.
Ты мня извини, но прежде чем кидаться что-то объяснять можно спросить у того кому собрался объяснять, а "не знает ли он этого?". Так вот отвечу — знаю. Но ленивость и чистота в Хаскеле ваимозависимые вещи. Желание сделать весь код линивым вынуждает делать его чистым, а полная чистота требует ленивости. Монады же призваны обходить оба ограничения делая вычисления последовательными и модифицирующими в казалось бы чисто-фукнциональном языке. Другими словами они эмулируют то что в других языках есть штатно: императивность и объектную ориентацию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Перечитай мой первый пост. Я указал тебе на то, что ты путаешь IO-монаду и монаду вообще.
Суть от этого не меняется. Утверждение "монады нужны хаскелю для обхода сосбвенной чистоаты и ленивости" не становится не верным. И утверждение "в ООЯ применение монад бессмысленно" тоже.
В общем, так как показать необходимость монад в ООЯ вы не в силах вопрос читаю ичепраным.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали: L>Например, показав, что запрос в LINQ является монадой мы можем быть уверены (т.к. это доказано на более общем уровне), что m.Select(x => x) == m или то же самое с SelectMany. Что x.SelectMany(f).SelectMany(g) == x.SelectMany(x => f(x).SelectMany(g)) ну и так далее.
О, вот это уже интересно. А можно продемонстрировать путь такого доказательства? Я правильно понимаю, что для него нам понадобится умение выполнять из Select(IEnumerable<T> this, Predicate<T> predicate) декомпозицию в Bind и что-то еще, а потом анализировать свойства этого чего-то еще?
L>Я понимаю, что это практикующему программисту не нужно но от этого он вряд ли лишается права глядеть на LINQ как на монаду.
Нет, я все это понимаю, и уметь увидеть в вызове процедуры на паскале композицию кортежа — очень полезно для развития воображения. Но мне кажется, что роль монад в Linq сильно преувеличена. Под определенным углом можно увидеть почти все что угодно во всем, что угодно. C некоторой точки зрения оператор switch, виртуальные методы, и обработчики исключений можно рассматривать как частные случаи паттерн-матчинга. Но особенной ценности это рассмотрение нам не даст, особенно если учесть, что вторые и третьи были придуманы во многом для того, чтобы избавиться от первого.
L>Но только ты показал, что именно не понятно
Ну, я наверное умею тупить наиболее убедительно
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Суть от этого не меняется. Утверждение "монады нужны хаскелю для обхода сосбвенной чистоаты и ленивости" не становится не верным. И утверждение "в ООЯ применение монад бессмысленно" тоже.
Последнее, очевидно, ложно. Если я применяю монады в ООЯ, то это имеет определенный смысл.
VD>В общем, так как показать необходимость монад в ООЯ вы не в силах вопрос читаю ичепраным.
Необходимость монад даже в ФЯ показывать никто и не предлагал.
Здравствуйте, VladD2, Вы писали:
VD>Блин, для особо упертых... Да, паттерн, но паттерн Хаскеля. В ООЯ ему просто нет места. Конечно его даже можно изобразить на ООЯ в которых поддерживаются функциональные объекты, но вот нужны в нем нет, так как есть другие подходы более естесвне6нные для этих языков.
Никто не говорил о нужде.
VD>Так нам будут показаны куски LINQ в которых используются монады?
Здравствуйте, VladD2, Вы писали:
L>>Я показывал общие свойства.
VD>Ничего ты не показал.
Влад, если тебе чего то непонятно, ты спрашивай
L>>Допустим, мы разрабатываем конкретную монаду в C#. Ну, предположим, у нас есть время поизвращаться. Дальше код условный, я на С# не пишу.
VD>Вот с этого надо и начинать было. "С# и занимаюсь гипотетическими рассуждениями...".
Ну тебе то незнание монад не мешает производить их оценку, верно?
Здравствуйте, VladD2, Вы писали:
VD>По сути же соверешнно согласен. Ребата натрепались, а теперь духу не хватет признаться, что ошиблись.
По сути у меня мнение польностью противоположное. Тебе показали, а у тебя духу не хватает признать, что ты ошибся. Вот и начинаешь говорить — где показали, да ещё раз покажите.
Здравствуйте, VladD2, Вы писали:
VD>Так. Извини, но мне надоело принимать в бесполезной словесной переплаке. Ты встал в ряд демагогов. Если будет сказть что-то интересное, то я с удовольствием выслушаю. А смотреть на словесную эквилибристику и контр-аргументацию в стиле "нет не белое, а белое" не не интересно.
Надоело — не принимай. Демагогией же пока занимаешься ты, не списывай, пожалуйста, свои достоинства на меня.
Заявить, что "белое — это когда белое, только не совсем белое", а потом удивляться, что ему возражают, ты умеешь.
VD>>>Из двух решений всегда надо выбрить более простой и понятное если коенчнь оно подходит L>>Нет. Из двух решений всегда надо выбирать подходящее
Ладно, поправлю фразу. БОЛЕЕ подходящее. Так пойдёт?
Заметь простота тут не указывается
VD>Адью.
Здравствуйте, VladD2, Вы писали:
VD>Какой бред, а?! Какие перечисления? Перечисление конечно по определению.
Если бы такое "уменьшение" было бы благом, то в Хаскеле даже числа были бы перечислениями объявленными в каком-нить модуле
VD>А числа бесконечны. Это в Хаскеле было принято идиотское решение считать числа перечислением. Вот пусть и решают сами же созданные проблемы. А я лучше у арабов поучусь. Пишу 1 получаю "один". Пишу 1 и еще 1, т.е. 11, получаю "один десяток и один" или "одинащцать". И никаких идеологических проблем.
Не поверишь, в Хаскеле тоже так можно. И тоже никаких идеологических проблем!
Это у Вадлера он в однобуквенных идентификаторах. Я старался избавиться от них, оставляль только в очевидных случаях типа Add x y 
Блин, я хринею. Взял и практически повторил свой исходный пример. на "простейший интерпретатор" это мало похоже. Простейший я уже приводил. Плюс в исходниках Немела есть "сложнеший", т.е. интерпретатор самого Немерла.
но от этого он вряд ли лишается права глядеть на LINQ как на монаду.
1.2.0 alpha rev. 655
