Хаскель и separation of concerns

[metaclass]

fp, cмерть мерзкая от монад, хаскель, штанга, гроб, гроб, кладбище
http://juick.com/2165512

Можно ли на всем этом сделать так: https://gist.github.com/4292029
И чтобы goodProcessingFunction можно было нормально комбинировать из отдельных кусков, вплоть до того, что явно определить точки, где данные юзера становятся данными для девайса и наоборот.
Или например, обощить это, прикрутив еще и какой-нибудь tcp сервер.

Т.е. у нас есть несколько независимых IO каналов, каждый со своими форматами данных, на каждый канал прикрутить сменный парсер-сериализатор, чтобы в ядро бизнес-логики этот канал приходил уже в виде значений нормальных типов.
А потом еще захочется хранить в бизнес-логике состояние, подключаться к БД и все это, по-моему, нахрен умрет под грузом типов и слоев монад.

Comments

[jakobz.livejournal.com]

Чувак, что yesod делает, носится с какими-то своими conduit-ами. Ну типа там делает чтобы оно было composable с одной стороны, было бы быстрым и нормально освобождало ресурсы с другой. Ты не про это?
http://www.yesodweb.com/blog/2012/06/conduit-0-5

[metaclass.livejournal.com]

Про это, да.
Я так и не понял, почему он заменил iteratees на кондуиты.
Хотя я почти сделал вышеописанное на итератерах.

[nivanych.livejournal.com]

Тоже непонятно, какие-такие существенные преимущества оно даёт.
Разве что, попроще работать "with those scary resources", но имхо, проще было постараться и сделать это же под итераты, это там ненамного сложнее, насколько я могу судить.

[gds.livejournal.com]

да, мне тоже малопонятно, в чём цимес кондуитов по сравнению с итератами.

[gds.livejournal.com]

nivanych попросил более подробного описания картины, как с ресурсами в итератах, и я описал ему приватно, но опубликую тут тоже.
Контекст: я сделал простой http-сервер на окамле, на lwt (зелёные треды), на итератах (моя либка ocaml-iteratees), и вполне доволен. Сервер умеет в том числе принимать заливаемые файлы.
"
например, заливку файла по хттп рассмотрим. Чтение из сокета -- enumerator, который кормит итерат-аргумент трафиком. Итерат-аргумент по завершении работы даёт http-ответ. На основании запроса и ответа вычисляется, стоит ли закрывать сокет, и при нужде сокет закрывается (или обработка продолжается). То есть, закрытие сокета осуществляется при выходе из функции, которой дают открытый сокет. Далее, итератор-аргумент получает данные, определяет, что хотят, и, если это заливка, вызывает функцию, берущую имя файла, возращающую итерат, открывающий файл, пишущий в файл все чанки, которые в этот итерат суют. Когда сунут EOF -- файл закроется, логика закрытия прописана в этом же итерате. А EOF сунут по-любому, когда в трафике встретится boundary, это гарантируется тем enumeratee, который режет mime multipart на куски и кормит кусками свой итерат-аргумент. То есть, тут вполне таки гарантии того, что и сокет будет закрыт (то есть, сокет будет либо работать на благо http, либо будет закрыт по окончании работы), и есть гарантии того, что по окончании mime-куска с заливаемым файлом этот файл будет закрыт.
"