О чистоте и лени
После N-ной провальной попытки изучить Haskell и понять суть религии под названием "монадический фетишизм", решил изобрести свой "велосипед", то есть чистый и ленивый язык программирования.
Для любой открытой системы важным моментов является взаимодействие с внешним миром. В данном случаем - порядок обмена информацией.
У энергичных языков порядок определяется непосредственно самой последовательностью инструкций в программе. Напротив, для ленивых языков последовательность выполнения инструкций неопределена, а значения вычисляются по мере необходимости. Поэтому для осуществления взаимодействия с внешним миром в ленивые языки порядок вводиться искусственно.
Одним из способов упорядочивания вычислений является ввод дополнительных переменных-маркеров, при помощи которых указываются дополнительные зависимости между подпрограммами. Например, подпрограмма "C" зависит от переменной "b", которая определяется в подпрограмме "B", в свою очередь подпрограмма "B" зависит от переменной "a", значение которой определяется в подпрограмме "A", что приводит к выполнению сначала подпрограммы "A", затем "B" и лишь затем "C". Эти переменные маркеры в Mozart-OZ получили название свободные (unbound) переменные, а в Clean - уникальные типы.
Другим способом упорядочивание вычислений является использование стиля передачи продолжений. Однако этот стиль труден для использования им требует модификации подпрограмм. К счастью последнего можно избежать при помощи подпрограммы-обертки. В Haskell этой оберткой является оператор bind, а монады по сути не что иное, как своеобразный "концептуальный сахар" над стилем передачи продолжений. В свою очередь Haskell оператор do является "синтаксическим сахаром" вокруг монад, создающих иллюзию того, что переменные меняют свое значение.
Так что на самом деле Haskell, как и Clean, - абсолютно чистый язык, а религия "монадический фетишизм" - удел тех, кто на видеть разницы между иллюзией и реальностью.
P.S.
Во загнул! С другой стороны, что взять с простого физ-химика, волей случая написавшего несколько маленьких программ на Perl.
Для любой открытой системы важным моментов является взаимодействие с внешним миром. В данном случаем - порядок обмена информацией.
У энергичных языков порядок определяется непосредственно самой последовательностью инструкций в программе. Напротив, для ленивых языков последовательность выполнения инструкций неопределена, а значения вычисляются по мере необходимости. Поэтому для осуществления взаимодействия с внешним миром в ленивые языки порядок вводиться искусственно.
Одним из способов упорядочивания вычислений является ввод дополнительных переменных-маркеров, при помощи которых указываются дополнительные зависимости между подпрограммами. Например, подпрограмма "C" зависит от переменной "b", которая определяется в подпрограмме "B", в свою очередь подпрограмма "B" зависит от переменной "a", значение которой определяется в подпрограмме "A", что приводит к выполнению сначала подпрограммы "A", затем "B" и лишь затем "C". Эти переменные маркеры в Mozart-OZ получили название свободные (unbound) переменные, а в Clean - уникальные типы.
Другим способом упорядочивание вычислений является использование стиля передачи продолжений. Однако этот стиль труден для использования им требует модификации подпрограмм. К счастью последнего можно избежать при помощи подпрограммы-обертки. В Haskell этой оберткой является оператор bind, а монады по сути не что иное, как своеобразный "концептуальный сахар" над стилем передачи продолжений. В свою очередь Haskell оператор do является "синтаксическим сахаром" вокруг монад, создающих иллюзию того, что переменные меняют свое значение.
Так что на самом деле Haskell, как и Clean, - абсолютно чистый язык, а религия "монадический фетишизм" - удел тех, кто на видеть разницы между иллюзией и реальностью.
P.S.
Во загнул! С другой стороны, что взять с простого физ-химика, волей случая написавшего несколько маленьких программ на Perl.
Теперь по сути
1) Что такое монады?
Ответ на этот вопрос вам не нужен. Это особые моноиды (полугруппы, кажется, по-русски), определенные для особых категорий в теории категорий. Ответ столь же бесполезен, как и знание того, что такое строгие функции (строгие функции - это не "функции, которые всегда используют свой аргумент", а функции, сохраняющие нижний элемент в особых частично упорядоченных множествах в теории доменов).
2) Что такое монады в Хаскеле?
Это особая абстрактная управляющая структура.
3) В чем польза хаскелевцам от наличия такого странного модуля, как Control.Monad?
Повторное использование кода. Функции из этого модуля вроде mapM и liftM2 удается повторно использовать в чрезвычайно большом количестве предметных областей. Монадический фетишизм заключается в том, что людей возбуждает, если функцию mapM удаётся применить в каком-то неожиданном месте. Т.е. пишешь-себе пишешь, а потом бах - обнаруживаешь: "Ба, да это я половину контрол-монад заимплементил, надо срочно выбросить 100 зря написанных строк и написать import Control.Monad". Собственно возбуждение наступает лишь в клинических случаях - люди учили монады чтобы делать ио, а потом прозрели, что оказывается в Хаскеле есть абстракции управления. В менее запущенных случаях человека возбуждают не только монады, а вообще все абстракции управления (стрелки, обобщенные свертки, функторы и аппликативные функторы, вся typeclassopedia). Но такие люди выглядят не фанатами, а занудами, т.к. они не могут похвастаться знанием фраз типа "категория эндофункторов", а "абстракции управления" - это недостаточно заумно, т.к. и "абстракция", и "управление" есть даже в книгах по джаве. С другой стороны, люди, бросающиеся на каждом углу словами "катаморфизм", не производят впечатления фетишистов, так как рядовому кодеру непонятно, зачем это нужно, когда можно писать рекурсивную лапшу. В случае монад же вопрос "зачем нужен ввод-вывод" покажется нелепым даже императивному программисту, так что их как-то приходится постигать всем.
4) Зачем ввод-вывод в Хаскеле организован таким странным образом?
Это уже не монадический фетишизм, а пуристический. Об этом в следующем комментарии
Re: Теперь по сути
Монадический фетишизм
В PDF всё можно найти на CiteSeerX (просто поискав "monads for functional programming CiteSeerX" на Гугле). Вот список чего Вадлер написал по монадам и связанным темам:
http://homepages.inf.ed.ac.uk/wadler/topics/monads.html
Re: Монадический фетишизм
Так я и пытался в этой заметке именно это и сказать, что что do-нотация - лишь красивая запись, и которая для тех, кто хочет, может создать иллюзии. Более того, что монады - это тоже сахарок над продолжениями, в чем усилилась моя уверенность после прочтения http://blog.sigfpe.com/2008/12/mother-of-all-monads.html.
Кстати, когда писал про неопределенность порядка подразумевал не на уровне всей программы, о чем вы говорили, а не уровне отдельно взятого куска кода, функции.
Ведь внутри функции не известно как там снаружи средуцируется граф, и какая переменная, то есть значение, получаемое из вне этой функцией понадобиться первым.
А продолжения позволяют связать функции так, что не выполнив одну, нельзя выполнить другую. Другим способом это сделать - unbound переменные в OZ.
> В PDF всё можно найти на CiteSeerX (просто поискав "monads for functional programming CiteSeerX" на Гугле). Вот список чего Вадлер написал по монадам и связанным темам:
>
> http://homepages.inf.ed.ac.uk/wadler/topics/monads.html
Спасибо.
P.S.
Вы как-то грозились написать красиво об этом всем.
Стоить надеяться на это в ближайшие время?
Написать красиво