tag:blogger.com,1999:blog-6031647961506005424.post7020765686577939431..comments2023-10-09T20:19:28.997+03:00Comments on Lisp, the Universe and Everything: О страшных монадахVsevolod Dyomkinhttp://www.blogger.com/profile/07729454371491530027noreply@blogger.comBlogger32125tag:blogger.com,1999:blog-6031647961506005424.post-45574277875868264072011-10-20T15:45:20.869+03:002011-10-20T15:45:20.869+03:00@rigidus Да, спасибо за поправку@rigidus Да, спасибо за поправкуVsevolod Dyomkinhttps://www.blogger.com/profile/07729454371491530027noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-33560804996040979992011-10-20T12:44:13.341+03:002011-10-20T12:44:13.341+03:00мне кажется что в макросе and-it есть ошибка в зап...мне кажется что в макросе and-it есть ошибка в запятой: <br />нужно <br />"(t `(let ((it ,(first args)))<br />а не <br />(t `(let ((it (first ,args)))<br />я прав?rigidushttps://www.blogger.com/profile/02878404387716367105noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-29600239568249086442010-03-28T17:05:52.926+03:002010-03-28T17:05:52.926+03:00@thesz, не совсем понял, к чему это относится: к т...@thesz, не совсем понял, к чему это относится: к тому, что выражение "стратегия вычисления" уже занято и означает несколько иное. Возможно. Значит, можно подобрать более точный термин из предметной области. Впрочем, в той же википедии написано (http://en.wikipedia.org/wiki/Monads_in_functional_programming): "monad is a kind of abstract data type used to represent computations".Vsevolod Dyomkinhttps://www.blogger.com/profile/07729454371491530027noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-14383151658887738362010-03-28T14:59:57.686+03:002010-03-28T14:59:57.686+03:00http://en.wikipedia.org/wiki/Evaluation_strategy
...http://en.wikipedia.org/wiki/Evaluation_strategy<br /><br />Находится по "computation strategy".<br /><br />Что там об "использование нетипичной для предметной области терминологии — это аттрибут троллинга"? ;)<br /><br />Монады обозначают вполне определённую пару отображений (функций) и предоставляют интерфейс соединения последовательных вычислений. "Перегруженная точка с запятой" (что используется, например, в <a href="http://repetae.net/repos/jhc/src/Grin/" rel="nofollow">GRIN</a>)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-53737817202017334622010-02-15T15:39:56.925+02:002010-02-15T15:39:56.925+02:00@ADEpt Проблема, на которую я пытался указать, зак...@ADEpt Проблема, на которую я пытался указать, заключается в том, что берутся понятия из одной предметной области и пересаживаются в другую. Это приводит к тому, что для большинства программистов, которые не имеют соответствующей базы, нет предпосылок для понимая этих концепций (и возникает напряжение, которое хорошо выражено в приснопамятном посте zabivator'а). Почему эту алгебраическую/категорную терминологию не пытаются "приблизить" как-то к остальной мне не понятно. То ли считаются (слышал такие заявления), что это не нужно — ну, тогда вечно и будут продолжаться эти споры, – то ли не понимается этого момента, то ли это создает какой-то ореол научности. Возможно, все вместе. (Я не отрицаю, что в основе Haskell реальная, настоящая наука. Но также и в основе инженерии физика и математика, но терминология все равно своя, и совсем иные принципы).<br />Итак, возвращаясь к методам в Java: название, кстати, идет из CLOS и означает конкретный (специализированный) способ выполнения той или иной операции (функции). Как по мне, оно из "общечеловеческой" что ли области, поэтому не является концептуальным барьером. Можно еще взять другие примеры (даже из ФП): замыкание — в данном случае имеет смысл, весьма отличный от математического,— свёртка — то же не соответствует тому, что в математике. Но благодаря такой терминологии, сами концепции становятся легче для понимания. Разве нельзя монаду также объяснить простыми словами? (я попытался: может быть и не удачно) ТО же касается и моноидов, стрелок, функторов: ведь в данном случае мы оперируем конкретными экземлярами этих концепций...Vsevolod Dyomkinhttps://www.blogger.com/profile/07729454371491530027noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-9774274501487598352010-02-15T15:10:41.825+02:002010-02-15T15:10:41.825+02:00Хотелось бы заметить, что название monad - это тол...Хотелось бы заметить, что название monad - это только один из представителей длиииного ряда названий, взятых "из теории": Functor, Applicative, Monoid, Traversable, Foldable, Monad.<br /><br />И именно поэтому не нужно заниматься заменой терминов. Это...мммм... ну как если бы в java предложить заменить слово "method" на "operation" - ведь в большнинстве случаев в теле метода указывается последовательность операций :)<br /><br />Хорошая библиография по теме: http://squadette.livejournal.com/599819.htmlADEpthttps://www.blogger.com/profile/16464838579540251181noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-40966181956907440702009-11-12T05:42:23.206+02:002009-11-12T05:42:23.206+02:00> "Today we will start learning about the ...> "Today we will start learning about the case statement." (http://learnhaskell.blogspot.com/2007/09/lesson-3-case-3.html)<br /><br />case .. of (сопоставление с образцом) не имеет никакого отношения к заданию порядка побочных эффектов.<br /><br />> есть разница между применяется и является основой. Вполне возможно, что операция + в каком-то языке будет не ассоциативной<br /><br />Я говорил об операции сложения для натуральных чисел. Конечно, при overflow ассоциативность не выполняется.<br /><br />>>> Что касается монад для управления состоянием. Согласитесь, что это только один из способов, альтернатива которому, явно передавать состояние через вызовы функций<br /><br />>> Ну я нигде не утверждал обратное, совсем.<br /><br />> Вы сказали, что монады "нужны" для управления состоянием. А я сказал, что они "нужны" для управления порядком вычислений. Нет?<br /><br />Гм. Вы уже совсем запутались, и запутали меня. :) ("Управление состоянием" -- слишком размытый термин, "управление порядком вычислений" тоже.)<br /><br />> Возможно, есть еще какие-то составляющие программирования, которые приводят к тому, что мы все-таки обсуждаем, стоит ли последовательность вычислений задавать через монады или через statements и т.п.? Как вы считаете? ;)<br /><br />Я считаю, что иногда лучше одно, а в иных случаях другое.Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-5560166026206987442009-11-11T14:20:10.192+02:002009-11-11T14:20:10.192+02:00@Artyom
> Зачем? Вы же просто уводите разговор ...@Artyom<br />> Зачем? Вы же просто уводите разговор в сторону.<br />У меня, к сожалению, сложилось такое же впечатление и о некоторых ваших ответах<br /><br />> Есть только ближайший эквивалент: вычисление в монаде IO.<br />"Today we will start learning about the case statement." (http://learnhaskell.blogspot.com/2007/09/lesson-3-case-3.html)<br /><br />> Ну просто это слишком уж поверхностное рассуждение, извините.<br />ничего страшного :)<br /><br />> В программировании разве не применяется арифметика?<br />есть разница между применяется и является основой. Вполне возможно, что операция + в каком-то языке будет не ассоциативной (например, в PHP можно "сложить" число и строку. Вполне может быть, что это неассоциативно: например, просиходит неявное приведение типов к типу первого аргумента. Лень проверять, если честно).<br /><br />> Что же касается этого вопроса, то я могу только сказать, что сообщество Haskell генерирует очень много интересных идей. Некоторые из них могут оказаться полезными.<br />Полностью согласен, о чем написал в предыдущей заметке<br /><br />> Мы же не с теоретической точки зрения рассматриваем?<br />Вот именно!<br /><br />> Что это? Как строятся выражения этого языка? Как он интерпретируется?<br />аналог Haskell без монад ;) (т.е.<br />main = do<br />print 1<br />while (True): do nothing<br />мы записать не сможем)<br /><br />> Ну я нигде не утверждал обратное, совсем.<br />Вы сказали, что монады "нужны" для управления состоянием. А я сказал, что они "нужны" для управления порядком вычислений. Нет?<br /><br />> Программирование это software engineering. Всякий engineering строится на точных науках. В случае с SE это будет CS и математика. Может быть, Вы знаете о каких-то альтернативных основах для программирования?<br />С научной точки зрения, как мы уже согласились, программа на С и на Haskell эквивалентны. Т.е. нет предмета для нашей дискуссии. Возможно, есть еще какие-то составляющие программирования, которые приводят к тому, что мы все-таки обсуждаем, стоит ли последовательность вычислений задавать через монады или через statements и т.п.? Как вы считаете? ;)Vsevolod Dyomkinhttps://www.blogger.com/profile/07729454371491530027noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-50454154122904320132009-11-11T14:01:07.980+02:002009-11-11T14:01:07.980+02:00> мне кажется, мы как-то с вами говорим немного...> мне кажется, мы как-то с вами говорим немного на разных языках<br /><br />Да, вероятно.<br /><br />> А вы сначала ответьте на мой вопрос про Python ;)<br /><br />Зачем? Вы же просто уводите разговор в сторону.<br /><br />> а еще на такой: в Haskell'е есть "инструкции" (statemets)?<br /><br />Есть только ближайший эквивалент: вычисление в монаде IO.<br /><br />> Разве я сразу не сказал? ("Это приводит к разделению (дублированию) синтаксиса")<br /><br />Ну просто это слишком уж поверхностное рассуждение, извините.<br /><br />> Про GetCols опять же ответа нет<br /><br />Просто я еще не проверил, потому что для этого мне нужно прочитать ту статью, ознакомиться с кодом, а потом уже ответить. Может быть Вы сведете задачу к наименьшей возможной?<br /><br />> Мы говорим о программировании, а не об арифметике.<br /><br />В программировании разве не применяется арифметика? (Пример с плюсом и 0 показан был лишь для того, чтобы сравнить его с >>= и return: return является для >>= единичным элементом -- прям как 0 для +, >>= ассоциативен -- как +)<br /><br />> Разница в том, что рассматривается вопрос, может ли ипрограммирование на Haskell позволить достигнуть лучшего качества кода по человеко-центричным метрикам (поддерживаемость, модульность, понятность и т.д.).<br /><br />Вроде бы рассматривался вопрос "о страшных монадах", а тут вдруг качество кода...<br /><br />Что же касается этого вопроса, то я могу только сказать, что сообщество Haskell генерирует очень много интересных идей. Некоторые из них могут оказаться полезными.<br /><br />> Ведь с теоретической точки зрения программа на C и программа на Haskell Тьюринг-эквивалентны, т.е. разницы между ними нет.<br /><br />Мы же не с теоретической точки зрения рассматриваем?<br /><br />> Хорошо, у нас есть программа:<br />print 1<br />while (True): do nothing<br /><br />Что это? Как строятся выражения этого языка? Как он интерпретируется?<br /><br />> Глобального состояния нет, но если не задан порядок вычислений, то print 1 может выполнится, а может нет, так ведь? Зачем нам такая программа? ;)<br /><br />Как такую программу выразить в лямбда-исчислении? Давайте говорить предметно, по Вашему псевдокоду мне ничего не понятно.<br /><br />> Что касается монад для управления состоянием. Согласитесь, что это только один из способов, альтернатива которому, явно передавать состояние через вызовы функций<br /><br />Ну я нигде не утверждал обратное, совсем.<br /><br />> (по сути, монады это и делают, только скрывая. пример: do-нотация)<br /><br />Да, только вот монады можно использовать для много другого: например, для продолжений (в вебе особенно полезно), для реактивного программирования, etc. И нет, do-нотация ничего такого не скрывает.<br /><br />> мы снова говорим на разных языках: программирование -- это не научная дисциплина, не путайте с Computer Science. Это гуманитарная дисциплина: тут нужно, чтобы humanity восприняло ;)<br /><br />Программирование это software engineering. Всякий engineering строится на точных науках. В случае с SE это будет CS и математика. Может быть, Вы знаете о каких-то альтернативных основах для программирования?Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-85511482256202319952009-11-11T13:29:43.518+02:002009-11-11T13:29:43.518+02:00@Artyom
мне кажется, мы как-то с вами говорим немн...@Artyom<br />мне кажется, мы как-то с вами говорим немного на разных языках<br /><br />> А теперь укажите на неверность моего утверждения<br />А вы сначала ответьте на мой вопрос про Python ;)<br />а еще на такой: в Haskell'е есть "инструкции" (statemets)?<br /><br />> Ах, Вы о синтаксисе<br />Разве я сразу не сказал? ("Это приводит к разделению (дублированию) синтаксиса")<br /><br />Про GetCols опять же ответа нет<br /><br />> Теперь представьте, на что будет похожа арифметика, если операция сложения не будет ассоциативна, а нуль не будет ее нейтральным элементом.<br />Мы говорим о программировании, а не об арифметике. Разница в том, что рассматривается вопрос, может ли ипрограммирование на Haskell позволить достигнуть лучшего качества кода по человеко-центричным метрикам (поддерживаемость, модульность, понятность и т.д.). Ведь с теоретической точки зрения программа на C и программа на Haskell Тьюринг-эквивалентны, т.е. разницы между ними нет.<br /><br />> Нет изменяемого состояния -- нет необходимости в указании порядка его изменения.<br />Хорошо, у нас есть программа:<br />print 1<br />while (True): do nothing<br /><br />Глобального состояния нет, но если не задан порядок вычислений, то print 1 может выполнится, а может нет, так ведь? Зачем нам такая программа? ;)<br />Что касается монад для управления состоянием. Согласитесь, что это только один из способов, альтернатива которому, явно передавать состояние через вызовы функций (по сути, монады это и делают, только скрывая. пример: do-нотация)<br /><br />> Использование этого термина в какой-либо научной публикации или по историческим причинам.<br />мы снова говорим на разных языках: программирование -- это не научная дисциплина, не путайте с Computer Science. Это гуманитарная дисциплина: тут нужно, чтобы humanity восприняло ;)Vsevolod Dyomkinhttps://www.blogger.com/profile/07729454371491530027noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-39263331588530084272009-11-11T06:31:02.329+02:002009-11-11T06:31:02.329+02:00Упс, не дописал про программистов на Haskell.
>...Упс, не дописал про программистов на Haskell.<br /><br />> в принципе, да. А как по вашему определить принадлежность терминологии определенной сфере?<br /><br />Использование этого термина в какой-либо научной публикации или по историческим причинам.<br /><br />> Как по мне, это общеупотребимость и одинаковая трактовка всеми. Следует она из того, что какая-то группа людей начинает активно использовать, а затем подтягиваются все остальные.<br /><br />Это говорит только распространенности термина.<br /><br />> Понятно, что акждый термин вводится в определенный момент, но он может как прижится, так и нет. Это определеяется тем, насколько он связан с дргой терминологией, насколько адекватен, насколько точно описывает предмет. В случае с монадами это, к сожалению, не совсем наблюдается.<br /><br />Эпитеты "адекватен", "связан с другой терминологией", "точно описывает предмет" оставим на потом. Монады имеют (а) точное математическое определение, (б) связь с теорией категорий (которая, в свою очередь -- связь с другими разделами математики), (в) большую абстрактность (наверное, именно это и является основной проблемой для их понимания).Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-39161795823284909632009-11-11T06:24:45.068+02:002009-11-11T06:24:45.068+02:00> Как по мне, это общеупотребимость и одинакова...> Как по мне, это общеупотребимость и одинаковая трактовка всеми. Следует она из того, что какая-то группа людей начинает активно использовать, а затем подтягиваются все остальные.<br /><br />Хорошо, значит, Вы утверждаете, что программисты на Haskell<br /><br />> А как вы определелили его безграмотность?<br /><br />Не нашел нигде определения, что же <br />это такое. Есть версия, что это "ООП без наследования", но определения ООП тоже нигде нет.<br />Впрочем, это уход от темы.<br /><br />> toplevel для того кода, который вы написали это let что-то = что-то in что-то<br /><br />(let val = exp in body) является обычным выражением. <br /><br />> PL/1, Cobol, Lisp, Smalltalk, Mathematica, Forth, Shell (bash), ... -- да очень много языков в разных сферах и разные времена были весьма распространенными.<br /><br />Ну давайте на примерах. Я пытаюсь показать, что программы на Си, Cobol и Shell состоят из:<br />- математических выражений (которые не могут состоять из инструкций)<br />- инструкций (которые состоят из математических выражений)<br />- функций/процедур (которые группируют инструкции)<br /><br />В Си: [x + 1] это выражение, [int a = x + 1;] это инструкция (statement), а [int inc(int x) {int a = x + 1; return a * 2;}] это функция.<br /><br />Причем надо заметить, что выражения не могут состоять из инструкций (в Си это правило нарушается, в результате -- undefined behavior). Пример: [x++ + x++] -- что дает вычисление этого выражения? Выполняется ли равенство [(x++ + x++) + x++)] = [x++ + (x++ + x++)]?<br /><br />А теперь укажите на неверность моего утверждения:<br /><br />> Мейнстримные языки обычно поддерживают два вида "вычислений": математические выражения и инструкции (statements), причем вторые обычно нужны для того, чтобы задать порядок побочных эффектов.<br /><br />Достаточно будет показать один мейнстримный (=широко используемый в индустрии, например, Java, C#, etc.) язык, который не использует инструкции для указания порядка побочных эффектов. Вы ведь это утверждение хотели опровергнуть, так?<br /><br />> Тем не менее, вы не ответили на мой вопрос<br /><br />Этот вопрос не относится к теме разговора. Я даже не буду предполагать, зачем Вы его задали.<br /><br />> я понял. я про =<br /><br />Ах, Вы о синтаксисе... В общем-то, никакой разницы.<br /><br />> http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm<br />Там есть вызов getCols. Он соблюдает ссылочную целостность?<br /><br />> здесь (http://www.haskell.org/all_about_monads/html/laws.html) написано иначе<br /><br />Теперь представьте, на что будет похожа арифметика, если операция сложения не будет ассоциативна, а нуль не будет ее нейтральным элементом.<br /><br />> http://norvig.com/design-patterns/img007.gif <br /><br />Да, там на слайде как раз подтверждение. Спасибо.<br /><br />> Мне почему-то кажется, что монады были введены для того, чтобы справится с ленивостью (т.е. неопределенным порядком вычислений -- в некоторых случаях его таки нужно четко определять, да), а не с немутируемыми состоянием.<br /><br />Нет изменяемого состояния -- нет необходимости в указании порядка его изменения.<br /><br />> Как по вашему справляются с этим OCaml, Erlang, Clojure, в которых монад в явной форме нет? (ну, то есть, это, по-моему, риторический вопрос)<br /><br />Попробуйте вычислить выражение [(\x -> 1) (myglobal := 4)] строго, а затем нестрого (не вычисляя выражение [myglobal := 4] (да, это будет выражение, как set! в Scheme), потому что для завершения вычисления оно не нужно).Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-65066590673773395292009-11-10T13:31:57.471+02:002009-11-10T13:31:57.471+02:00> То есть Вы теперь считаете, что если термин &...> То есть Вы теперь считаете, что если термин "монада" употребляет, скажем, только пара программистов из того списка, то он не относится к программированию?<br />в принципе, да. А как по вашему определить принадлежность терминологии определенной сфере? Как по мне, это общеупотребимость и одинаковая трактовка всеми. Следует она из того, что какая-то группа людей начинает активно использовать, а затем подтягиваются все остальные. Понятно, что акждый термин вводится в определенный момент, но он может как прижится, так и нет. Это определеяется тем, насколько он связан с дргой терминологией, насколько адекватен, насколько точно описывает предмет. В случае с монадами это, к сожалению, не совсем наблюдается.<br /><br />> А если (безграмотный) термин "object-based" говорят многие, то он относится к программированию?<br />А как вы определелили его безграмотность?<br /><br />> соответственно вычисление производится по ленивому принципу (поскольку монады в toplevel не фигурируют).<br />toplevel для того кода, который вы написали это let что-то = что-то in что-то<br /><br />> Э... ну какие же?<br />PL/1, Cobol, Lisp, Smalltalk, Mathematica, Forth, Shell (bash), ... -- да очень много языков в разных сферах и разные времена были весьма распространенными.<br /><br />> Наличие в Python оператора yield никоим образом не влияет на наличие в том же Python разделения на выражения и инструкции.<br />Тем не менее, вы не ответили на мой вопрос<br /><br />> Нет, return в Haskell и ключевое слово return не имеют ничего общего.<br />я понял. я про =<br /><br />> Это возможно только для монады IO и только с использованием unsafePerformIO. Может быть, что и при использовании FFI что-нибудь вылезет (не могу сказать, FFI почти не пользовался).<br />Вот вам пример: http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm<br />Там есть вызов getCols. Он соблюдает ссылочную целостность?<br /><br />> В коде ее можно будет использовать, но не наравне с монадами.<br />здесь (http://www.haskell.org/all_about_monads/html/laws.html) написано иначе<br /><br />> Монады это не паттерны. (!) Паттерны проектирования (а) не подчиняются никаким законам, (б) не абстрагируются языком программирования (поэтому их каждый раз нужно реализовывать заново).<br />http://norvig.com/design-patterns/img007.gif <br /><br />> Изменение переменной -- побочный эффект, потому что функция, которая изменяет переменную, выполняет что-то еще (а именно это изменение) кроме вычисления своего результата. Но с помощью изменяемых переменных можно получить много полезного, например, состояние. Как получить то же самое, но без изменения переменных?<br />Мне почему-то кажется, что монады были введены для того, чтобы справится с ленивостью (т.е. неопределенным порядком вычислений -- в некоторых случаях его таки нужно четко определять, да), а не с немутируемыми состоянием. Как по вашему справляются с этим OCaml, Erlang, Clojure, в которых монад в явной форме нет? (ну, то есть, это, по-моему, риторический вопрос)Vsevolod Dyomkinhttps://www.blogger.com/profile/07729454371491530027noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-74046185516098314752009-11-10T12:56:48.406+02:002009-11-10T12:56:48.406+02:00> перестаньте уже переходить на
> личности,...> перестаньте уже переходить на <br />> личности, и позвольте же вести <br />> техническую дискуссию.<br /><br />Ок, удаляюсь, пойду лучше писать код ;)archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-28535234190303112792009-11-10T12:49:00.398+02:002009-11-10T12:49:00.398+02:00Ах, дорогой archimag, перестаньте уже переходить н...Ах, дорогой archimag, перестаньте уже переходить на личности, и позвольте же вести техническую дискуссию. Если Вам есть что дополнить или подкорректировать, то Вы всегда это можете сделать.Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-24687628385364145562009-11-10T12:44:17.990+02:002009-11-10T12:44:17.990+02:00> Монады это не паттерны. (!)
> Паттерны пр...> Монады это не паттерны. (!) <br />> Паттерны проектирования <br /><br />Ну я же говорю, что не хватает кругозора, ну при чём тут "Паттерны проектирования"? Паттерны и "Паттерны проектирования" это ведь не одно и тоже? Блин, Вы же спорите с человек, который пишет на Common Lisp, а не на C#, учитывайте это :)))archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-26883346752756174352009-11-10T12:39:22.727+02:002009-11-10T12:39:22.727+02:00> Как по мне, в первую очередь оно зависит от п...> Как по мне, в первую очередь оно зависит от принятия его авторитетами в предметной области (или у вас другой критерий?)<br /><br />Вроде бы у Вас был другой критерий (про количество).<br /><br />> Если выделить из них тех, кто активно пишет/выступает, то сколько из этих употребляет термин "монада"? Мне кажется, -> 0<br /><br />То есть Вы теперь считаете, что если термин "монада" употребляет, скажем, только пара программистов из того списка, то он не относится к программированию? А если (безграмотный) термин "object-based" говорят многие, то он относится к программированию?<br /><br />> соответственно вычисление производится по ленивому принципу (поскольку монады в toplevel не фигурируют).<br /><br />Монада IO фигурирует в top-level (main :: IO a), если я правильно понял, что под top-level Вы понимаете main. Причем тут "ленивый принцип"? (и что это?)<br /><br />> Вам нужно было сказать не мейнстримные, а языки из Algol-семейства (среди мейнстримных было, есть и будет еще много других).<br /><br />Э... ну какие же?<br /><br />> На счет того же Python: оператор yield вы к какому классу относите?<br /><br />Наличие в Python оператора yield никоим образом не влияет на наличие в том же Python разделения на выражения и инструкции.<br /><br />> Т.е. в "мейнстримном" языке было бы: a = e, return f(a), так ведь? И для случая, когда e -- "обычное" значение, и когда оно -- в монаде (блин, терминологии нормальной нет или я ей, просто, не владею). Нет?<br /><br />Нет, return в Haskell и ключевое слово return не имеют ничего общего. Но операцию bind в IO-монаде можно считать за этакую "точку с запятой".<br /><br />> Это возможно?<br /><br />Это возможно только для монады IO и только с использованием unsafePerformIO. Может быть, что и при использовании FFI что-нибудь вылезет (не могу сказать, FFI почти не пользовался).<br /><br />> Она не будет монадой в математическом смысле, но в коде вы ее сможете использовать наравне с другими "Haskell монадами<br /><br />В коде ее можно будет использовать, но не наравне с монадами.<br /><br />> Это я к тому, что все равно, как и другие паттерны, этот нужно понимать и правильно реализовывать.<br /><br />Монады это не паттерны. (!) Паттерны проектирования (а) не подчиняются никаким законам, (б) не абстрагируются языком программирования (поэтому их каждый раз нужно реализовывать заново).<br /><br />> Возможно. (Покажите контр-пример).<br /><br />main = putStrLn "foo" >> putStrLn "bar"<br /><br />Такая программа, хоть и бесполезна, не требует глубокого знания монад.<br /><br />> А какое отношение к монадам имеет немутируемость переменных? И еще: это сравнение происходит каждый день :)<br /><br />Изменение переменной -- побочный эффект, потому что функция, которая изменяет переменную, выполняет что-то еще (а именно это изменение) кроме вычисления своего результата. Но с помощью изменяемых переменных можно получить много полезного, например, состояние. Как получить то же самое, но без изменения переменных? ... Тут не место для очередного туториала по монадам. ;)Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-88280339259073392872009-11-10T12:09:42.161+02:002009-11-10T12:09:42.161+02:00@Artyom
> Да, вообще-то самым конструктивным бы...@Artyom<br />> Да, вообще-то самым конструктивным было бы определить два языка, в одном из которых есть изменяемые переменные, а в другом -- нету, и сравнить стиль программирования на каких-то "реальных" задачах.<br />А какое отношение к монадам имеет немутируемость переменных? И еще: это сравнение происходит каждый день :)Vsevolod Dyomkinhttps://www.blogger.com/profile/07729454371491530027noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-69649942270464479672009-11-10T12:09:26.605+02:002009-11-10T12:09:26.605+02:00@Artyom
> Нет. Во-первых, отношение термина к п...@Artyom<br />> Нет. Во-первых, отношение термина к предметной области не зависит от *количества* людей, которые его знают<br />Как по мне, в первую очередь оно зависит от принятия его авторитетами в предметной области (или у вас другой критерий?)<br />Авторитетов в программировании много (можно ориентироваться, например, на http://en.wikipedia.org/wiki/List_of_programmers. Если выделить из них тех, кто активно пишет/выступает, то сколько из этих употребляет термин "монада"? Мне кажется, -> 0).<br /><br />> in -- это синтаксический сахар. let val = exp in body означает нечто вроде "дать выражению exp имя val в выражении body".<br />Правильно, соответственно вычисление производится по ленивому принципу (поскольку монады в toplevel не фигурируют).<br /><br />> Тогда я не понимаю, что, по-Вашему, такое "энергичные" и "ленивые" вычисления?<br />То же самое, что и у других.<br />Когда я говорил про стратегии вычисления, то имел в виду: вычисления, которые могут прерваться в любой момент, вычисления с мемоизацией и т.д. и т.п. То, будут они ленивыми или энергичными -- это уже технический (можно сказать, более низкоуровневый) аспект реализации. К сожалению, ни термин монада, ни стратегия вычисления не являются абсолютно адекватными. Трудно придумать хорошую терминологию, согласен.<br /><br />> Да ну, правда? :) C/C++, Java, JS, Python, Fortran и еще целая куча языков построена именно на таком принципе.<br />Вам нужно было сказать не мейнстримные, а языки из Algol-семейства (среди мейнстримных было, есть и будет еще много других). На счет того же Python: оператор yield вы к какому классу относите?<br /><br />> Разумеется, нет. do-запись это синтаксический сахар: do {a <- e; return (f a)} это тоже самое, что и e >>= \a -> return (f a).<br />Т.е. в "мейнстримном" языке было бы: a = e, return f(a), так ведь? И для случая, когда e -- "обычное" значение, и когда оно -- в монаде (блин, терминологии нормальной нет или я ей, просто, не владею). Нет?<br /><br />> Во-первых, ссылочную целостность лучше называть "подставляемостью", а определяется она так: f(x) = f(x), где f -- произвольная функция, а x -- такой аргумент, для которого f определена. Если в языке все переменные неизменяемы, и нет способа вызвать что-нибудь такое, что даст наблюдаемый эффект, то вряд ли есть способ нарушить ссылочную целостность. (что-то мне в голову не приходят контрпримеры, но я их поищу, интересно :))<br />Так в том то и дело, что нет смысла в языке, где нет такого способа. Поэтому и в Haskell, например, можно сделать так: внутри f используется "монада" (конструкция языка, не математический объект), которая дает непредсказуемый эффект, соответственно ссылочная целостность не соблюдается. Это возможно?<br /><br />> Во-вторых, программисты выясняют, подчиняется ли монада законом или нет сами. К тому же, построить монаду, которая не будет подчиняться законам можно, просто это не будет монадой. :)<br />Она не будет монадой в математическом смысле, но в коде вы ее сможете использовать наравне с другими "Haskell монадами", и это может привести к непредсказуемым результатам. ("Any type constructor with return and bind operators that satisfy the three monad laws is a monad. In Haskell, the compiler does not check that the laws hold for every instance of the Monad class. It is up to the programmer to ensure that any Monad instance he creates satisfies the monad laws.")<br />Это я к тому, что все равно, как и другие паттерны, этот нужно понимать и правильно реализовывать.<br /><br />> А что там абстрагировать? Там нет даже лишних повторений. Но если сильно хочется, то можно объявить новую монаду, внутри которой и спрятать этот трансформер.<br />Ну, можно попробовать. Было бы интересно глянуть.<br />А абстрагировать нужно не только повторения, но, самое главное -- сложность.<br /><br />> Слишком сильное обобщение.<br />Возможно. (Покажите контр-пример).Vsevolod Dyomkinhttps://www.blogger.com/profile/07729454371491530027noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-76446843113198740652009-11-10T11:31:27.695+02:002009-11-10T11:31:27.695+02:002 archimag
> Я же предпочитаю писать код, кото...2 archimag<br /><br />> Я же предпочитаю писать код, который считаю единственным критерием.<br /><br />Да, это понятно. Тогда Ваши слова о "неверной аргументации", пожалуй, ничего не значат.<br /><br />> Я бы ещё понял обсуждения в стиле: вот мой код (только не в 20 строк), делающий что-то интересное, а вот код на других языках, и так много раз.<br /><br />Да, вообще-то самым конструктивным было бы определить два языка (через написание интерпретаторов), в одном из которых есть изменяемые переменные, а в другом -- нету, и сравнить стиль программирования на каких-то ("реальных", хотя тут обычно начинаются разногласия) задачах.Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-35252511191264565072009-11-10T11:24:51.243+02:002009-11-10T11:24:51.243+02:00> Сказавши "а", говорите и "б&qu...> Сказавши "а", говорите и "б".<br /><br />Не вижу в этом смысла, в последнее время и так было достаточно "достойных" примеров обсуждений и кажется не все ещё остыли :) Я же предпочитаю писать код, который считаю единственным критерием. Я бы ещё понял обсуждения в стиле: вот мой код (только не в 20 строк), делающий что-то интересное, а вот код на других языках, и так много раз. Я просто поговорить теоретически это как бы не очень интересно.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-8162790034264843022009-11-10T11:14:47.667+02:002009-11-10T11:14:47.667+02:002 archimag
> Ну, поскольку данный блог во мног...2 archimag<br /><br />> Ну, поскольку данный блог во многом посвящён Common Lisp, то наверное с него и надо начинать?<br /><br />Дискуссия-то идет о Haskell и монадах, не так ли? Причем здесь Лисп и все-все-все? Очень похоже на попытку задать strawman argument (ведь на остальные, гораздо более важные аргументы Вы ничего не ответили).<br /><br />> Стратегия вычислений одна из ключевых концепций, излагаемая в SICP.<br /><br />Неужели это такая сложная штуковина, что ее нельзя определить одним предложением и подкрепить парой примеров?<br /><br />(и да, под стратегией вычислений я понимаю evaluation strategy aka reduction strategy в лямбда-исчислении)<br /><br />> Вы же, кажется, не совсем поняли этот термин, и отсюда идёт неверное понимание поста и неверная аргументация.<br /><br />Тогда Вам следует указать, как и где именно я заблуждаюсь. Сказавши "а", говорите и "б".Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-61083515310795406012009-11-10T11:08:17.701+02:002009-11-10T11:08:17.701+02:00> Что же, спуститесь до моего уровня,
> и п...> Что же, спуститесь до моего уровня, <br />> и покажите эти Ваши "много других языков".<br /><br />Ну, поскольку данный блог во многом посвящён Common Lisp, то наверное с него и надо начинать?<br /><br />> Поясните, как моя скромная персона <br />> относится к предмету обсуждения?<br /><br />Стратегия вычислений одна из ключевых концепций, излагаемая в SICP. И ссылка в посте на "стратегию вычислений" мгновенно развеяла туман у меня в голове по поводу монад. Вы же, кажется, не совсем поняли этот термин, и отсюда идёт неверное понимание поста и неверная аргументация.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-26859122876224990292009-11-10T11:02:26.480+02:002009-11-10T11:02:26.480+02:00> Придя, обычно, в haskell именно из Мейстрима ...> Придя, обычно, в haskell именно из Мейстрима (включая C) они часто кажется не подозревают, что есть ещё много других языков. <br /><br />Что же, спуститесь до моего уровня, и покажите эти Ваши "много других языков".<br /><br />> Кажется, Artyom Shalkhakov просто не читал SICP :)<br /><br />Поясните, как моя скромная персона относится к предмету обсуждения?Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.comtag:blogger.com,1999:blog-6031647961506005424.post-41920206274594123832009-11-10T10:58:15.107+02:002009-11-10T10:58:15.107+02:00> Понимаете, от того, что кто-то начал что-то п...> Понимаете, от того, что кто-то начал что-то пропагандировать, это не стало понятным большиству программистов.<br /><br />Нет. Во-первых, отношение термина к предметной области не зависит от *количества* людей, которые его знают (можно говорить только о распространенности, не более того). Во-вторых, понимание -- штука весьма сложная и неоднозначная. Могу сказать, что например MVC и ООП понимает очень мало народу, хотя все вроде бы пользуются, но это тема для другого разговора.<br /><br />> call-by -- это calling convention (соглашение о вызове). А стратегрия вычисления...<br /><br />Стратегия вычисления (evaluation strategy) это не более чем набор правил, описывающих операции, которые можно производить над выражениями. Соглашение вызова это реализация стратегии вычислений на компьютере. Не вижу противоречия.<br /><br />> in -- это монадная операция или нет?<br /><br />Нет, это синтаксический сахар. let val = exp in body означает нечто вроде "дать выражению exp имя val в выражении body". Например, в scheme есть let (отличается от let в haskell!) и letrec (наиболее близкий аналог).<br /><br />> Мы с вами говорим о разных понятиях: я не о calling convention, а о разных подходах к организации вычислительных процессов.<br /><br />Тогда я не понимаю, что, по-Вашему, такое "энергичные" и "ленивые" вычисления?<br /><br />> Но есть же монады, которые выполняют побочные эффекты, нет?<br /><br />"Выполняют"? Скорее "производят", ну да без разницы.<br /><br />Да, разумеется. Но что считать побочным эффектом? Можно сказать, что Maybe моделирует побочный эффект, заключающийся в прерывании дальнейшего вычисления. Maybe просто абстрагирует паттерн.<br /><br />> Все намного сложнее, да и языков много, в каждом свои особенности<br /><br />Да ну, правда? :) C/C++, Java, JS, Python, Fortran и еще целая куча языков построена именно на таком принципе.<br /><br />> Самый простой пример: = и <-.<br /><br />Разумеется, нет. do-запись это синтаксический сахар: do {a <- e; return (f a)} это тоже самое, что и e >>= \a -> return (f a).<br /><br />> Мне показалось, что ссылочная целостность будет гарантированно соблюдена<br /><br />Во-первых, ссылочную целостность лучше называть "подставляемостью", а определяется она так: f(x) = f(x), где f -- произвольная функция, а x -- такой аргумент, для которого f определена. Если в языке все переменные неизменяемы, и нет способа вызвать что-нибудь такое, что даст наблюдаемый эффект, то вряд ли есть способ нарушить ссылочную целостность. (что-то мне в голову не приходят контрпримеры, но я их поищу, интересно :))<br /><br />Во-вторых, программисты выясняют, подчиняется ли монада законом или нет сами. К тому же, построить монаду, которая не будет подчиняться законам можно, просто это не будет монадой. :)<br /><br />> Можно ли, не меняя подход (т.е. решая через монады State и Maybe), абстрагировать монадный трансформер?<br /><br />А что там абстрагировать? Там нет даже лишних повторений. Но если сильно хочется, то можно объявить новую монаду, внутри которой и спрятать этот трансформер.<br /><br />> Или вы считаете, что монадный трансформер со своим особым синтаксисом и т.д. имеет какое-то отношение к этой предметной области?<br /><br />У монадных трансформеров нет своего особого синтаксиса. :) Монадный трансформер может и не относится к предметной области (о какой мы говорим? я запутался уже), но его там почти и нету.<br /><br />> Я сказал, что не удастся в Haskell'е абстрагировать употребление монад, а оно, в целом, довольно сложное и далеко от предметной области.<br /><br />Это субъективно, не принимается. Точно также я могу заявить, что макросы -- это сложно и далеко от предметной области. ;)<br /><br />> Т.е. если вы в Lisp'е можете написать программу практически полностью на языке предметной области<br /><br />Я рад за лисперов.<br /><br />> в Haskell определенный базис (включающий монады) всегда будет оставаться в любой программе.<br /><br />Слишком сильное обобщение.<br /><br />> Я специально посмотрел первую главу книги про DSL в Haskell (Астапова) и убедился в этом. Сравните, например, с таким простейшим примером: http://lispm.dyndns.org/mov/dsl-in-lisp.mov (125 MB)<br /><br />Что-то у меня нет желания скачивать 125MB ради примера.Artyom Shalkhakovhttps://www.blogger.com/profile/08658644954244073101noreply@blogger.com