Ссылка с planet haskell, IO monad

[metaclass]

Теперь про IO.
В ссылке с прошлого поста товарищ жалуется на то, что IO монада лезет в любую дыру без мыла и заражает в итоге любую более менее осмысленную программу.

В этом плане я не совсем понимаю, почему в хаскеле эта монада - одна на все виды взаимодействия с внешним миром? Например, с моей точки зрения чтение и запись файлов совершенно отличается от обращения к серверу БД, что в свою очередь отличается от разговора с пользователем в консоли, что опять же отличается от взаимодействия в GUI, итд. Еще можно вспомнить работу по сети, работу с COM-портами, FFI итд.

Предположительно, было бы гуманно дать программистам возможность самостоятельно делать IO-подобные монады и расселить разные виды взаимодействия по разным монадам, заодно как-то прикрутить к этим монадам некие атрибуты на тему ленивости и порядка вычислений - т.е. например, запись в лог без разницы в каком порядке будет делаться и вообще должна вычисляться только тогда, когда это значение кому-то интересно.

Это я как-то размышлял на тему, "как бы выглядел хаскель, встроенный в СУБД в качестве языка запросов". Я с трудом могу перейти от размышления над обычной программой в стиле "запустили, ввели данные, получили результат" к постоянно запущенной программе, управляемой событиями типа "сервер, ждет запроса от клиентов" или "GUI приложение ждет нажатия кнопки пользователем".
И от "программа читает файл с состоянием, обрабатывает запрос и сохраняет файл обратно" к "программа живет с внутренним состоянием, которое обрабатывается интегрированным в компилятор/виртуальную машину/интерпретатор движком БД.
Реализация IO мешается в голове, а для СУБД нужна была бы еще одна монада (а может и не одна), отражающая внутреннее состояние, упорядочивающая действия с записями, транзакциями и взаимодействием между различными пользователями, лезущими к одним и тем же данным).

PS: Напомнили в комментариях - эта идея у меня возникла еще потому, что монада IO как бы таскает с собой "состояние внешнего мира". А это самое состояние - оно ни разу не монолитное, и его, если по хорошему, нужно разбить на несколько частей ("пользователь", "файлы", "базы данных", "сторонние системы").

Comments

[akuklev.livejournal.com]

IO-монада просто реализует (семантически необходимое) проведение по цепи выполнения объекта "State of the World". Более грамотно было бы конечно создать класс монад этого типа, позволяющих создавать монады, отвечающие разным аспектам этого самого State of the World. В первую очередь для различения State of the External World и внутреннего (сиречь инкапсулированного) состояния мутабельных объектов. Все такие специализированные монады этого типа теоретически можно реализовать поверх общей IO, но практически, к сожалению, неудобно.

[nealar.livejournal.com]

Патамушта:
1. IO жостко связывается с многозадачностью (в каком языке самые зеленые треды, ага?). Чтобы обращение одного потока к БД, _ВНЕЗАПНО_ не застопорило все остальные.
2. Инерция мышления. По уму, надо бы эти вещи разгрести и сделать _чистые_ функции доступа к БД, специальную низкоуровневую монаду для компортов, монаду Филе, которая делает POSIX-образный доступ к файлам и т.п.

[migmit.vox.com (from livejournal.com)]

> было бы гуманно дать программистам возможность самостоятельно делать IO-подобные монады

А какие с этим проблемы?

Можно писать интерпретирующие монады. Можно ограничивать IO. Можно делать что-то среднее. Простор для творчества.

[nivanych.livejournal.com]

Разбить-то можно.
Но как ты этими частями общаться между собой будешь?
Кучу трансформеров городить?
Впрочем, тут тов.migmit придумал чего-то интересное, надо посмотреть подробнее.
В любом случае, разработчики посчитали, что так, как сейчас, будет практичнее.
Если тебе надо, сам и делай кучу монад на твои жизненные случаи ;-)
Они очень даже бывают, конечно.
Сергей тоже вот правильно говорит.

[http://users.livejournal.com/_slw/]

это потому что авторы были испорчены библиотекой турбовижен, которая все -- потомок одного класса!