В смысле теории категорий - это абстракция, соответствующая определенным критериям. Это всё черная магия, дальше не знаю.
В контексте программирования - такой способ (паттерн, как любят некоторые говорить) решать задачи. Суть в том, что определяется ф-я, которая "прячет" подробности передачи результатов одной ф-ии в другую.
Впечатление следующее -- монады можно рассматривать как обобщение continuation-passing и accumulator-passing style (по крайней мере, в Scheme). Монады являются способом представить последовательность вычислений в чисто функциональном стиле. Поскольку именно наличие последовательности не позволяет вписать побочные эфффекты в декларативное программирование, то подобное представление последовательных вычислений дает возможность и любые (?) побочные эффекты представлять в чистом функциональном выражении.
А чем не устраивают те, что есть? Начал писать подробнее и понял, что в определении _нечего_ конкретизировать и упрощать. Может вопрос не про "определение"?
> Впечатление следующее -- монады можно рассматривать как обобщение
> continuation-passing и accumulator-passing style (по крайней мере, в
> Scheme).
Я не силен в теории, посему хотелось бы уточнить. Что там, по сути,
неявный accumulator passing - это я вроде понял. А вот CPS тут с какого
боку? Или я про них все-таки чего-то не понял?
Да, я ковырялся конкретно с хаскеллевкими монадами (ибо без них там жить
тяжко).
>Монады являются способом представить последовательность вычислений в чисто функциональном стиле. Поскольку именно наличие последовательности не позволяет вписать побочные эфффекты в декларативное программирование...
По правде говоря это возможно без монад. Просто такой код выглядит очень коряво.
Однако во многих случаях он может быть представлен в виде "последовательности" вызовов ф-й, "однообразно" передающих друг другу некий "параметр". В этом случае ?иногда? можно вынести обработку/передачу "параметра" в отдельную ф-ю/комбинатор, "инкапсулирующий" общую/повторяющуюся часть. Удобно, чтобы этот комбинатор удовлетворял некоторым условиям, которые ?случайно? оказываются эквивалентными тому, что в теории категорий соответствует "монадам".
Есть ли какая-то _практическая_ польза от этого сходства, кроме возможности стащить у математиков занятное название, я не знаю.
Однако струткурированый таким образом код при наличии синтаксической поддержки (типа do{} в Haskell) очень хорошо выглядит.
Т.о. монады (IMHO) стоит рассматривать как удобный, в некоторых случаях, способ структуризации кода (в программистском смысле; христиане и математики имеют на это свои мнения:-)
> Однако во многих случаях он может быть представлен в виде
> "последовательности" вызовов ф-й, "однообразно" передающих друг другу
> некий "параметр". В этом случае ?иногда? можно вынести
> обработку/передачу "параметра" в отдельную ф-ю/комбинатор,
> "инкапсулирующий" общую/повторяющуюся часть. Удобно, чтобы этот
> комбинатор удовлетворял некоторым условиям, которые ?случайно?
> оказываются эквивалентными тому, что в теории категорий соответствует
> "монадам".
Спасибо за внятное объяснение "на пальцах" - кажется, я действительно
понял более-менее правильно. Причем сам - и это радует =)
Кстати, надо будет почитать математическую часть на досуге. "Случайно
оказываются ..." - это уже интересно... ;)
> А вот CPS тут с какого боку? Или я про них все-таки чего-то не понял?
Я думаю, что Вы все правильно поняли :) Просто и APS, и CPS можно рассматривать как проявления одного паттерна -- передача по цепочке вызовов дополнительного параметра, явно содержащего информацию, необходимую для продолжения вычислений. А уж что там в нем, в этом параметре передается -- функтор или значение -- не так важно.