Возможный дубликат:
Что такое монада?
Как бы вы описали монаду в не-программировании? Есть ли какая-то концепция/вещь вне программирования (вне всего программирования, а не только FP), который можно было бы сказать, чтобы действовать или быть монадоподобным значительным образом?
Здесь мой текущий удар:
Монады - это ведровые бригады:
>>=, операция).return - это просто операция поместить материал в ведро.>>) содержимое ведра сбрасывается до того, как они будут переданы следующему человеку. Следующему человеку все равно, что было в ведре, они просто ждут его.() билет пропускается внутри ведра. Он назывался "Единица", и это просто чистый лист бумаги.Надеюсь, это поможет.: -)
Изменить: Я ценю вашу поддержку, но, к сожалению, проклятие Monad Tutorial пробило еще раз. То, что я описал, является просто функциональным приложением с контейнерами, а не с монадами! Но я не нигилист - я считаю, что проклятие Monad Tutorial может быть нарушено! Итак, вот несколько более сложная картина, которая, по-моему, описывает ее немного лучше. Вы решаете, стоит ли брать ваших друзей.
Монады - это ведровая бригада с руководителями проектов. Руководители проектов стоят за всеми, кроме первого члена бригады. Члены ведровой бригады сидят на табуретах и перед ними стоят ведра.
Первый человек получает кое-что, делает что-то с ним и помещает его в ведро. Этот человек тогда уходит - не к следующему человеку в бригаде, это было бы слишком легко!:-) - но менеджеру проекта стоит за этим человеком.
Менеджер проекта (ее имя связывается, или >>=) берет ведро и решает, что с ним делать. Она может принять решение вытащить из ведра материал первого человека и просто передать его лицу перед ней без дальнейших церемоний (это монада IO). Она может выбрать бросить ведро и закончить бригаду (это fail). Она может решить просто обойти человека перед собой и передать ведро следующему менеджеру в бригаде без дальнейших церемоний (что происходит с Nothing в монаде Maybe). Она даже может принять решение вытащить материал из ведра и передать его человеку перед собой за один раз! (Что Монада списка.) В случае последовательности (>>) она просто ударяет плечо человека перед собой, вместо того, чтобы передавать им какие-либо вещи.
Когда следующий человек создает ведро вещей, человек передает его следующему менеджеру проекта. Следующий руководитель проекта снова выясняет, что делать с ведром, которое она дала, и вручает вещи в ведро своей персоне. В конце, ведро передается обратно в цепочку менеджеров проектов, которые могут по желанию делать вещи с ведром (например, монада List, собирающая все результаты). В результате первый менеджер проекта создает ведро вещей.
В случае синтаксиса do каждый человек фактически является операцией, которая определена на месте в контексте всего, что было раньше - как если бы менеджер проекта проходил не только то, что было в ведре, но и (er, stuff), которые были созданы предыдущими членами бригады. Построение контекста в этом случае намного проще, если вы выберете вычисление с использованием привязки и последовательности вместо синтаксиса do - обратите внимание, что каждый следующий "оператор" представляет собой анонимную функцию, созданную в операции, которая предшествовала этой точке.
(), IO-монады и операция return остаются описанными выше.
"Но это слишком сложно! Почему люди не могут просто выгружать ведра сами?" Я слышу, как вы спрашиваете. Ну, руководитель проекта может сделать кучу работы за кулисами, которые в противном случае усложнили бы работу человека. Мы пытаемся упростить работу этих членов бригады, поэтому им не нужно делать слишком много. Например, в случае Модификации Maybe каждый человек не должен проверять ценность того, что им дано, чтобы увидеть, были ли они даны Nothing - менеджер проекта позаботится об этом для них.
"Ну, тогда, если вы снова пытаетесь облегчить работу каждого человека, почему бы не пройти весь путь - попросите человека просто взять вещи и передать материал, и пусть менеджер проекта беспокоится о bucketing?" Это часто делается, и у него есть специальное имя, называемое лишением человека (эр, операция) в монаду. Иногда, однако, вы хотите, чтобы у человека было что-то более сложное, где ему нужен некоторый контроль над созданным ведром (например, нужно ли возвращать Nothing в случае монады Maybe) и что то, что обеспечивает монада в полной общности.
Точки:
Таким образом заканчивается мой учебник по постели.:-P
Да, есть несколько вещей вне программирования, которые можно назвать похожими на монады. Нет, никто из них не поможет вам понять монады. Пожалуйста, прочитайте Абстракция, интуиция и "ошибка руководства монады" :
Джо Хаскеллер пытается узнать о монадах. После попытки понять их в течение недели, глядя на примеры, написание кода, чтение вещей, написанных другими людьми, у него наконец-то есть "ага!". момент: все внезапно ясно, и Джо понимает Монады! Конечно, на самом деле произошло то, что мозг Джоса объединил все детали вместе в абстракцию более высокого уровня, метафора, которую Джо может использовать, чтобы получить интуитивное понимание монадов; предположим, что метафора Джоса заключается в том, что Монады похожи на буррито. Здесь Джо плохо неверно истолковал свой собственный процесс мышления: "Конечно!" - думает Джо. "Все это так просто сейчас. Ключом к пониманию монадов является то, что они похожи на буррито. Если бы я думал об этом раньше!" Проблема, конечно же, в том, что если бы Джо подумал об этом раньше, это не помогло бы: неделя борьбы за детали была необходимой и неотъемлемой частью формирования интуиции Джоса Буррито, а не печальным следствием его неспособности нанести удар по идея раньше.
Но теперь Джо идет и пишет учебник монады под названием "Монады - это бурритос" под благонамеренным, но ошибочным предположением, что, если другие люди прочитают его магическое прозрение, изучение монад будет для них привязкой. "Монады легки, - пишет Джо." Думайте о них как о буррито. Джо скрывает все фактические данные о типах и т.д., Потому что это страшно, и люди будут лучше учиться, если смогут избежать всего этого трудного и запутанного материала. Конечно, прямо противоположно, и все, что сделал Джо, усложняют людям изучение монадов, потому что теперь им приходится тратить неделю, думая, что монады - это буррито и совершенно беспорядочно, а затем неделю пытается забыть о аналогии с буррито, прежде чем они смогут фактически перейти к изучению монадов.
Как я уже говорил в еще один ответ давно, статья sigfpe Вы могли бы придумать Монады! (И, возможно, у вас уже есть.), а также оригинальная статья Филиппа Вадлера "Монады для функционального программирования" - оба отличные представления ( которые дают не аналогии, но множество примеров), но помимо этого вы просто продолжаете кодирование, и в конечном итоге все это будет выглядеть тривиально.
[Не настоящий ответ: одно место монады существуют вне всякого программирования, конечно, в математике. Как этот веселый пост указывает: "Монада - моноид в категории эндофунторов, какая проблема?": -)]
Изменить. Вопрос, кажется, интерпретировал этот ответ как снисходительный, говоря что-то вроде "Монады настолько сложны, что они не соответствуют аналогии". На самом деле ничего подобного не предназначалось, и это монады-аналоги, которые часто кажутся снисходительными. Возможно, я должен повторить свою мысль как " Вам не нужно понимать монады". Вы используете определенные монады, потому что они полезны - вы используете монаду Maybe, когда вам нужно. Может быть, типы, вы используете монаду IO, когда вам нужно делать IO, аналогично другие примеры, и по-видимому, в С#, вы используете методы Nullable < > pattern, LINQ и запросов и т.д. Теперь понимание того, что существует общая абстракция, лежащая в основе всех этих структур, которую мы называем монадой, не обязательно понимать или использовать определенные монады. Это то, что может стать запоздалой мыслью после того, как вы увидели более одного примера и узнали образец: обучение переходит от конкретного к абстрактному. Непосредственное объяснение абстракции, обращаясь к аналогии самой абстракции, обычно не помогает учащемуся понять, что это абстракция.
В непрограммируемых терминах:
Если F и G - пара сопряженных функторов, причем F слева сопряжена с G, то композиция G.F является монадой.
Есть ли какая-то концепция/вещь вне программирования (вне всех программирование, а не только FP), которые можно было бы сказать, чтобы действовать или быть монад-подобными в Значительный путь?
Да, на самом деле есть. Монады совершенно напрямую связаны с "возможностью" в модальной логике расширением изоморфизма Карри-Говарда. (См.: Судебная реконструкция модальной логики.)
Это довольно сильные отношения, и для меня понятия, связанные с возможностью на логической стороне, более интуитивные, чем те, которые связаны с монадами из теории категорий. Лучший способ, который я нашел, чтобы объяснить монады моим ученикам, опирается на эти отношения, но без явного проявления изоморфизма.
Основная идея заключается в том, что без монадов все выражения существуют в одном мире, и все вычисления выполняются в этом мире. Но с монадами может быть много миров, и расчет движется между ними. (например, каждый мир может указывать текущее значение некоторого изменяемого состояния)
В этом представлении монада p означает "в возможном достижимом мире из текущего мира".
В частности, если t - тип, то:
x :: tозначает, что что-то типа t напрямую доступно в текущем мире
y :: p tозначает что-то типа t доступно в мире, доступном от текущего.
Затем return позволяет использовать текущий мир как достижимый.
return :: t -> p t
И >>= позволяет нам использовать что-то в достижимом мире, а затем достигать дополнительных миров из этого мира.
(>>=) :: p t -> (t -> p s) -> p s
Итак, >>= можно использовать для построения пути к достижимому миру из более мелких путей через другие миры.
С мирами, являющимися чем-то вроде состояний, это довольно легко объяснить. Для чего-то вроде монады IO это тоже довольно легко: мир определяется всеми взаимодействиями, которые программа имела с внешним миром.
Для нераскрытия достаточно двух миров - обычного и бесконечного в будущем. (Применяется → = со вторым миром, но вы вряд ли заметите, что происходит в этом мире.) Для монады продолжения мир остается прежним, когда продолжения используются обычно, и есть дополнительные миры, когда они (например, для callcc).
Из этот отличный пост Майка Ванье,
Одна из ключевых концепций в Haskell что отличает его от других Языки программирования - это концепция "монады". Кажется, люди находят это трудно учиться (я тоже), и в результате возникают нагрузки monad tutorials в Интернете, некоторые из которые очень хороши (я особенно как все о Монадах Джеффом Newbern). Было даже сказано, что написание учебника монады - обряд прохождение для новых программистов Haskell. Однако одна большая проблема со многими monad tutorials - это то, что они пытаются объясните, какие монады находятся в ссылке к существующим концепциям, которые читатель уже понимает (я даже видел это в выступлениях Саймона Пейтон-Джонс, главный автор Компилятор GHC и общий Haskell grand Poobah). Это ошибка, и я собираюсь рассказать вам, почему.
Это естественно, когда пытаешься объяснить что-то такое, чтобы объяснить это ссылка на вещи другого человека уже знает о. Это хорошо работает когда новое похожее в некоторых пути к тому, что другой человек знаком с. Он полностью разрушается когда новая вещь полностью отсутствует опыта человека изучая его. Например, если вы были пытаясь объяснить, какой огонь пещерный человек, который никогда не видел огня, что бы вы сказали? "Это вроде как пересечение воздуха и воды, но горячий..." Не очень эффективно. Точно так же, объясняя, что такое атом в терминах квантовая механика проблематична, потому что мы знаем, что электрон на самом деле не ядро, как планета вокруг звезды, и понятие "делокализованное электронное облако" на самом деле не означает много. Фейнман однажды сказал, что никто действительно понимал квантовую механику, и на интуитивном уровне это правда. Но на математическом уровне квантовый механика хорошо понята; Мы только не имеют хорошей интуиции для чего математика действительно означает.
Как это относится к монадам? Время и снова, в учебниках, сообщениях в блогах и в списках рассылки Haskell, я увиденные монады, объясненные в одном из двух предположительно-интуитивно понятным образом: монада "вроде как действие" или "вид как контейнер". быть как действием, так и контейнером? Разве это не отдельные понятия? Это монада какая-то странная "активная контейнер"? Нет, но дело в том, что утверждая, что монада - это своего рода действие или вид контейнера неверен. Так что же такое монада?
Здесь ответ: Монада - это чисто абстрактное понятие, без фундаментальное отношение ко всему вы, наверное, когда-либо слышали о раньше. Появляется понятие монады от теории категорий, которая является наиболее абстрактная ветвь математики я знать о. Фактически, весь смысл теория категорий - абстрагировать все от структуры математики до выявить сходства и аналогию между кажущимися разрозненными областями (для например, между алгеброй и топология), чтобы конденсироваться математики в ее фундаментальную концепций и, следовательно, уменьшить избыточность. (Я мог бы продолжить об этом довольно в то время как, но я предпочел бы вернуться к точка, которую я пытаюсь сделать.) Поскольку я угадывая, что большинство программистов обучение Haskell мало что знает о теория категорий, монады не идут что-то для них значит. Это не означают, что им нужно узнать все о теория категорий для использования монад в Хаскелл (к счастью), но он означают, что им нужно думать о вещах в более абстрактным способом, чем они, вероятно, используется.
Пожалуйста, перейдите по ссылке вверху сообщения, чтобы прочитать полную статью.
На практике большинство монад, с которыми я работал, ведут себя как неявный контекст.
Это нравится, когда вы и друг пытаетесь поговорить о другом. Каждый раз, когда вы говорите "Боб", вы оба ссылаетесь на одного и того же Боба, и этот факт просто неявно пронизан вашим разговором из-за того, что Боб является вашим общим другом.
Конечно, вы можете поговорить с вашим боссом (а не с вашим другом) о своем менеджере уровня skip-уровня (а не о вашем другом), который, как считается, называется Bob. Здесь вы можете иметь другой разговор, опять же с некоторой подразумеваемой коннотацией, которая имеет смысл только в контексте разговора. Вы даже можете произнести те же самые слова, что и с вашим другом, но они будут иметь другое значение из-за разного контекста.
В программировании он то же самое. Способ поведения tell зависит от того, в какой монаде вы находитесь; способ сборки информации (>>=) зависит от того, в какую монаду вы находитесь. Такая же идея, разный режим разговора.
Черт, даже правила разговора могут быть монадическими. "Не говорите никому, что я вам сказал" скрывает информацию так же, как runST предотвращает утечку ссылок на монаду ST. Очевидно, что разговоры могут иметь слои и слои контекста, точно так же, как у нас есть стеки монадных трансформаторов.
Надеюсь, что это поможет.
Хорошо, здесь красиво подробное описание монад, которое определенно выходит за рамки программирования. Я знаю это вне программирования, потому что я программист, и я не понимаю даже половины того, о чем он говорит.
Также существует ряд видеороликов на YouTube, объясняющих монады этого сорта - здесь первый в последовательности.
Я предполагаю, что не совсем то, что вы искали, хотя...
Мне нравится думать о них как о абстракциях вычислений, которые могут быть "связаны". Или, бурритос!
Это зависит от того, с кем вы разговариваете. Любое объяснение должно быть разбито на правильном уровне. Мое объяснение инженерам-химикам было бы отличным от моего объяснения математику или финансовому менеджеру.
Лучший подход - связать его с чем-то в экспертизе человека, с которым вы разговариваете. Как правило, секвенирование является довольно универсальной проблемой, поэтому постарайтесь найти что-то, что человек знает о том, где вы говорите: "Сначала сделайте X, затем сделайте Y". Затем объясните, как у обычных языков программирования есть проблема с этим; если вы скажете "сделайте X, затем сделайте Y" на компьютер, он сразу же X и Y не ждет ввода дополнительных данных, но тем не менее он не может выполнять Z за кого-то другого; компьютерная идея "а затем сделать" отличается от вашей. Поэтому программисты должны писать свои программы по-другому, чем объяснял вам (эксперт). Это создает разрыв между тем, что вы говорите, и тем, что говорит программа. Это стоит времени и денег, чтобы преодолеть этот пробел.
Монады позволяют помещать вашу версию "а затем делать" в компьютер, поэтому вы можете сказать "сделайте X, а затем выполните Y", и программист может написать "do {x; y}", и это означает, что вы имеете в виду.
Да, Монады происходят из концепции за пределами haskell. У Haskell есть много терминов и идей, которые были заимствованы из теории категорий. Это одна из них. Поэтому, если этот человек, который не является программистом, оказывается математиком, изучающим теорию категории, просто скажите: "Монада - моноид в категории эндофенторов".