Понял, а что ты юзаешь?

У меня Э-к, сокеты для устройств, web-сокеты для дальнего интерконнекта (если на обоих оконечниках Э-к).

http://gearman.org/ http://nanomsg.org/ - ссылочки в тему :)

Окей спасибо большое

А, да, еще отдельный цирк, когда сеть далека от тепличных условий. И когда требуется соблюсти порядок доставки сообщений.

в хацкель у него ещё и евентпол отдельный

А, да. Если падает zeromq - то падает вся аппликушка.

А оно падает... ну, не сильно редко.

Поэтому все делать надо с расчетом, что в любой момент прилетит.

да сигаборт на фейле какой-то операции меня порадовал

у меня сейчас проблема что он фд не закрывает хотя должен

и я в лимит влетаю

Огонь

собственно вместо того чтобы выдать ошибку он абортится

я боюсь что там паттерн использования кривой

ReaderT наше все?) https://www.fpcomplete.com/blog/2017/06/readert-design-pattern

ReaderT Env IO хорошая штука и правильно пишет, а после как обычно какую-то хреноту

ну т.е. не совсем хреноту, а как обычно

интересно, а то, что я с FP complete-овками разговаривал объясняя как мы используем такой паттерн повлияло на блог или нет

@qnikst А можешь пояснить, что за хренота? Ну, в смысле, что как и обычно

ReaderT Env IO удобно читать окружения, конфиги я так понял

это же вроде в Servant?

в общем ReaderT Env IO это половина того, что всегда надо

HasFoo класс типов это тоже хорошо, но я бы и методы в класс типов засунул т.к. можно переопределить иногда это важно

unsafePerformIO и котята это неверно, иногда оно очень надо

ну и там про State и ещё что-то странные размышления

то, что WriterT это монада для создания space leaks это верно (у него немного не так но смысл верный)

ну и его можно сделать правильным если через стейт написать, а стейт сам пофиксить или взять последние tf

ну и его можно сделать правильным если через стейт написать, а стейт сам пофиксить или взять последние tf

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

ну поидее writer не делает создает зависимость в собираемой части из-за этого проблемы

решается переписыванием через стейт

но там *> возникает

unsafePerformIO и котята это неверно, иногда оно очень надо

а котята это что?

а т.к. по дефолту *> пишется через <*> (в непоследних tf) то там форсится значение где не надо

в итоге память все равно выжирается

но это исправляется специальным *> для стейта

@async_prince IO a -> a

под локом

т.е. можно сделать thunk с IO действием в чистый контекст

там есть ряд проблем, и лучше не понимая что ты делаешь не трогать

@async_prince IO a -> a

ну это как раз unsafePerformIO, это я знаю, а котята это что?

а..

ну в топике что выше снойман написал, что котёнок умирает, когда это используют

а чем EitherT не угодил? мне нравится идея разделения на ошибки приложения и на все остальное(IO)

наверное в пользу ExceptT?

ExcepT поверх IO кучу проблем приносит

отсутствие MonadMask как минимальное

в итоге это заканчивается переизобретением исключений

у Сноймана есть статья но этому поводу (как обычно biased и opionated),\ но норм

он там доказывает для это бесполезно

я согласен что оно бесполезно для юзера либы, с другой стороны для пишущего либу есть плюсы, он видит, с чем он может валиться и что будет выше обработано пользователем, все остально нужно через throwM

часто ли такое случается - если честно не знаю

возможно, ExceptT и ErrorT станут экземплярами MonadMask https://github.com/ekmett/exceptions/pull/59

ExcepT поверх IO кучу проблем приносит

Каких проблем, не очень понимаю? По мне так исключения это дётихак. Не такой страшный как unsafePerformIO, но всё равно: чем ближе код к тайп-сейфному, тем лучше.

Vasiliy я не понимаю инстанса для ErrorT и почему он правильный..

@elemir90 хотя бы наличия monad mask и некомпозабельность, точнее композабельность с хаками

в итоге получается переихоюретение исключений

в итоге получается переихоюретение исключений

сложно новичку, столько терминов

@elemir90 не новичок, а писать для новичков я не всегда умею

:/

Я забросивший хаскель олдфаг, лол. Про монадмаск почитаю. А под "композабельностью" ты понимаешь невозможность состакать a и b в ErrorT a (... (ErrorT b ...))?

Vasiliy я не понимаю инстанса для ErrorT и почему он правильный..

я-то вообще ничего не понимаю, остаётся надеяться, что грамотные люди разберутся

один кусок возвращает одну ошибку, другой другую, в итоге нужно делать mapEitherT или как там его и их в одну структуру

Vasiliy release в bracket не отрабатывает в случае ошибки

если я не устал и не туплю

ERROR: S client not available

последнее вероятно

обычно жалобы на то, что чтобы слепить вместе ErrorT x m и ErrorT y m, нужно делать сумму x и y

+ case (eresource, eresult) of + (Left e, _) -> return $ Left e + (_, Left e) -> return $ Left e + (Right resource, Right result) -> runErrorT (release resource result))

ну вон жалоба эта 4мя сообщениями выше

а тут 2ой кейс

для него мы не вызываем release

обычно жалобы на то, что чтобы слепить вместе ErrorT x m и ErrorT y m, нужно делать сумму x и y

Объединение скорее. Потому что если пересечение типов x и y не пустое, то не надо его дважды включать

Монадмаск это https://hackage.haskell.org/package/exceptions-0.8.3/docs/Control-Monad-Catch.html ?

да

у меня смутное ощущение что проблема была в mask а не bracket

а понял

там проблема в "if the base monad provides no ability to provide multiple exit"

насколько я читал

точнее, наоборот, в этом случае проблем не будет, они будут, если есть возможность нескольких выходов

или как это по-русски сказать

да

в чем профит от монадмаск?

можно использовать mask

зачем mask и что такое асинхронные исключения знаешь?

можно пример?

Даже я не знаю

так начнем с асинхронных исключений

это такие исключение, которые можно послать в другой тред

соотв там в "произвольном месте" может возникнуть исключение что послали

обычно используют для прерывания тредов, но иногда и какой-то message passing с прерыванием выполнения делают

треду иногда не хочется чтобы его прибивали (как и в случае с сигналами), например хочется выделить ресурс и удалить в конце и чтобы ничего не помешало, или несколько действий которые должны быть все выполнены

для этого есть mask :: (forall b . IO b -> IO b) -> IO a -> IO a

так неправильно написал, ((forall b . IO b -> IO b) -> IO a) -> IO a

это наподобии метода withException?

соотвественно мы вызываем mask $ \release -> ... и в ... не может возникнуь исключение

release нужен чтобы снова разрешить исключению прилетать

например bracket пишется как: bracket a r f = mask $ \release -> do x <- a ey <- try $ release x r x either throwIO return ey

это такие исключение, которые можно послать в другой тред

Это наркомания какая-то. А какое теоретическое обоснование этого театра абсурда? В моё время исключение было просто разновидностью боттом-значения