Switch to MonadUnliftIO
YPares opened this issue · comments
Currently funflow uses monad-control, but everything it does with it could be done with the simpler http://hackage.haskell.org/package/unliftio , which sort of replaced it in most use cases.
The thing is that funflow already depends on unliftio
because it uses resourcet
, and in general it would be more aligned with the conduit ecosystem used in funflow-aws
or cas-hashable-s3
.
Their APIs are very similar, so the high level wouldn't change much, just the constraints.
My opinion is that we could remove the need for monad-control.
@nc6 What's your opinion on that?
Capability doesn't export any IO
capability. I'd probably use unliftio
for this, myself. (Capability, on the other hand, can derive HasError
and HasCatch
instances from MonadUnliftio
, if that's useful)
Yep, and the goal here is interoperability. A lot of libs have transitioned to unliftio, that's my original rationale.