Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>GlebZ,
GZ>>Если есть, можешь дать ссылку на описание мат. основы монад?
LCR>Lomeo садист LCR>Хотя может быть у тебя пойдёт лучше чем у меня. LCR>На всякий случай прими во внимание ещё пункт 6 в этом списке
Курилка,
GZ>>>Если есть, можешь дать ссылку на описание мат. основы монад?
LCR>>Lomeo садист LCR>>Хотя может быть у тебя пойдёт лучше чем у меня. LCR>>На всякий случай прими во внимание ещё пункт 6 в этом списке
Здравствуйте, Sinclair, Вы писали:
S>О, вот это уже интересно. А можно продемонстрировать путь такого доказательства? Я правильно понимаю, что для него нам понадобится умение выполнять из Select(IEnumerable<T> this, Predicate<T> predicate) декомпозицию в Bind и что-то еще, а потом анализировать свойства этого чего-то еще?
Да правильно понимаешь. Для SelectMany я думаю всё понятно. Для Select(x => y) надо показать, что он аналогичен SelectMany(x => {y}), где {y} — конструирование нового IEnumerable над одним элементом.
L>>Я понимаю, что это практикующему программисту не нужно но от этого он вряд ли лишается права глядеть на LINQ как на монаду. S>Нет, я все это понимаю, и уметь увидеть в вызове процедуры на паскале композицию кортежа — очень полезно для развития воображения. Но мне кажется, что роль монад в Linq сильно преувеличена. Под определенным углом можно увидеть почти все что угодно во всем, что угодно.
Ты прав.
В своё оправдание лишь скажу, что как минимум, я показал, как с помощью этого паттерна можно легко придти к решению задачи. Разве это не является практической ценностью?
S>C некоторой точки зрения оператор switch, виртуальные методы, и обработчики исключений можно рассматривать как частные случаи паттерн-матчинга. Но особенной ценности это рассмотрение нам не даст, особенно если учесть, что вторые и третьи были придуманы во многом для того, чтобы избавиться от первого.
Здравствуйте, VladD2, Вы писали:
GZ>>>А почему бы не через continuations? Можно доказать то же самое — но без термина монада. PM>>continuations выражаются через монады .
VD>ОК, господа трепачи. Вот вам C#. Монады вы на нем сотворите без проблем, это вы уже тут раз дващцать сказали. Тогда пользуясь истенностью вашего послендего утверждения "continuations выражаются через монады" и реализуйте, плиз, в C# continuations. Лично скажу вам огромное спасибо и поклонись до земли. Ну, а если кода не будет, то будем считать это силивом по полной порогрмме на чем и закончим эту дисскуссию.
Здравствуйте, VladD2, Вы писали:
VD>Ты мня извини, но прежде чем кидаться что-то объяснять можно спросить у того кому собрался объяснять, а "не знает ли он этого?". Так вот отвечу — знаю. Но ленивость и чистота в Хаскеле ваимозависимые вещи. Желание сделать весь код линивым вынуждает делать его чистым, а полная чистота требует ленивости. Монады же призваны обходить оба ограничения делая вычисления последовательными и модифицирующими в казалось бы чисто-фукнциональном языке. Другими словами они эмулируют то что в других языках есть штатно: императивность и объектную ориентацию.
Твоя ошибка в том, что чистота не требует ленивости. Ленивость — это оптимизация. Она может быть ручной(ML но не уверен), может быть автоматической (FPTL) либо постоянной как в Хаскель. Ленивость не есть свойство чистого функционального языка. Оно лишь оптимизирует конечный код.
Мне Хаскель (который я пока только подгрызываю в силу недостатка времени) интересен именно как лаборатория. Ты в первую очередь обращаешь на средства предоставляемые пользователю. Мне интересно, как из декларативщины получает эффективный императивный код. И тут в чистоте просто огромные возможности и потенциал. В чистом языке функция — это команда компилятору но не более того. В реальном коде функции просто уже не будет существовать в силу трансформации всех уравнений компилятором. Компилятор здесь может это себе позволить. В императиве инлайнинг — это детский лепет. Это больше похоже на SQL. Уже давно никто не исполняет команды записанные программистом. Выполняются эффективный граф команд полученный оптимизатором.
VD> Перечисление конечно по определению. А числа бесконечны.
Маленькая поправочка — в Хаскелле это не так.
Перечисление отдельно
class Enum a where
succ, pred :: a -> a
toEnum :: Int -> a
fromEnum :: a -> Int
enumFrom :: a -> [a] -- [n..]
enumFromThen :: a -> a -> [a] -- [n,n'..]
enumFromTo :: a -> a -> [a] -- [n..m]
enumFromThenTo :: a -> a -> a -> [a] -- [n,n'..m]
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Vermicious Knid, Вы писали:
VD>... VD>По-моему, зачательная демонстрация того, что простые и прямые решения лучше чем эмуляция. И не важно ради чего эта эмуляци делается, из соображений совместимости, или в пылу борьбы за чистоту.
Да-да-да.
Наш Вычислительный Центр продолжает исследования в области уточнения значений замечательных чисел. Очередной прорыв достигнут при помощи нового суперкомпьютера для точного вычисления единицы по формуле sin^2(x) + cos^2(x): теперь мы знаем, что среди первых тридцати миллионов знаков десятичного разложения нет отличных от нуля.
Это существенный прогресс по сравнению с предыдущим значением в миллион знаков. Зарубежные ученые встретили наши достижения завистливой критикой. "Вы страдаете &$%%!@ней", заявил профессор А. из НьюПорта, "которая не имеет никакого практического применения", а франзузский математик П. не замедлил ехидно поинтересоваться выбором числа x для вычислений и влиянием его точности на результаты.
На это наши ученые отвечают, не теряя достоинства:
Что касается выбора числа X, то в еще в прошлом году в Вестнике РАН уважаемый директор нашего ВЦ опубликовал статью, в которой полностью обосновал наш выбор. Полезность же наших работ может недооценить только человек, абсолютно не знакомый с наукой. Единица используется в огромном количестве теорем; в частности, новые результаты в очередной раз подтвердили основания теории функций комплексного переменного, обосновав принятое приближение для числа i = sqrt(-1) и окончательно похоронили ревизионистские поползновения империалистической науки.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Но менее фунционально. Ведь пример с исключениями останавливается на превой ошибке.
Монадный вариант тоже вываливается на первой ошибке. Так что функцонал тот же.
Здравствуйте, VladD2, Вы писали:
VD>К сожалению не всегда все очевидно m, a, s и т.п. просто сбивают с толка.
Эх.. Да, жаль сообщения редактировать нельзя.. Подправил бы. Но в целом не так уж важно.
VD> Что лично меня только укрепляет во мнении, что монады в импертивных языках не нужны,
Для меня это пока еще не совсем очевидно. Я еще планирую поиграться с монадой List, ходят слухи что с ее помощью можно довольно просто организовать list comprehension. Поглядим что из этого получится... Вполне может быть, что получится что-то страшное и неудобоваримое, но так чешутся руки попробовать...
Здравствуйте, lomeo, Вы писали:
VD>>Суть от этого не меняется. Утверждение "монады нужны хаскелю для обхода сосбвенной чистоаты и ленивости" не становится не верным. И утверждение "в ООЯ применение монад бессмысленно" тоже.
L>Последнее, очевидно, ложно. Если я применяю монады в ООЯ, то это имеет определенный смысл.
А ты применяещь монады в ООЯ? Нет? Значит очевидно нечто другое.
VD>>В общем, так как показать необходимость монад в ООЯ вы не в силах вопрос читаю ичепраным.
L>Необходимость монад даже в ФЯ показывать никто и не предлагал.
В ФЯ это никого не колышит. Ты покажи зачем они в ООЯ. Про не предлагал — это очевидная лож.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
VD>>Но менее фунционально. Ведь пример с исключениями останавливается на превой ошибке. M>Монадный вариант тоже вываливается на первой ошибке. Так что функцонал тот же.
Но есть же тот что не вываливается. И размер у него почти тот же.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
M>Для меня это пока еще не совсем очевидно. Я еще планирую поиграться с монадой List, ходят слухи что с ее помощью можно довольно просто организовать list comprehension.
Ходят слухи, что у Камила Скальски реализация list comprehension на макросах заняла окло одного дня. И так же есть предположение, что никакие выверты не позволят расшириь C# подобной фичей без измененения компилятора.
M>Поглядим что из этого получится... Вполне может быть, что получится что-то страшное и неудобоваримое, но так чешутся руки попробовать...
Любиш ужастики?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ходят слухи, что у Камила Скальски реализация list comprehension на макросах заняла окло одного дня. VD>И так же есть предположение, что никакие выверты не позволят расшириь C# подобной фичей без измененения компилятора.
Стоп. Ты сам мне объяснял почему немерлавцам пришлось для реализации list comprehension залезть в компилятор. Попросю быть объективным.
Здравствуйте, VladD2, Вы писали:
L>>А зачем вам монады в шарпе?
VD>Я плякаль.
Нет, ну на самом деле. Вспомни начало — ты сказал, что монады нужны для реализации императивности, поэтому они в шарпе не нужны (рассматривая LINQ). Я всего лишь указал, что эта частная монада, о которой ты рассуждаешь, нужна для реализации императивности. Поэтому твой вывод (в значении "выведение результата") неверен. Независимо от верности/неверности самого вывода (в значении "сам результат").
Я всего лишь сказал, что из того, что конкретные монады IO/State эмулируют императивность НЕЛЬЗЯ сделать вывод, что и все остальные монады не нужны в императивном языке. Для такого вывода нужны другие посылки. Всё.
Относительно того, монады нужны или не нужны — мне это неинтересно. И не смотря на это я понаприводил кучу примеров их возможного использования — ну вы же спрашиваете, может не знаете чего. В ответ получал только рекурсивное — а зачем они нужны? Зачем мне это приписывают, я не понимаю. Ну, разве что, чтобы не обсуждать то, с чем я действительно спорил, нет?
Здравствуйте, lomeo, Вы писали:
L>Относительно того, монады нужны или не нужны — мне это неинтересно. И не смотря на это я понаприводил кучу примеров их возможного использования — ну вы же спрашиваете, может не знаете чего. В ответ получал только рекурсивное — а зачем они нужны?
Есть подозрение что народ хочет увидеть такое применение монад, которое даст преимущество по сравнению с традиционным подходом..
То есть без монад — гемморой. А вот с монадами..
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
но от этого он вряд ли лишается права глядеть на LINQ как на монаду.
1.2.0 alpha rev. 655
Ты сам мне объяснял почему немерлавцам пришлось для реализации list comprehension залезть в компилятор.