Switch to MonadUnliftIO

[Ywen]

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?

[Mathieu Boespflug]

Or use http://hackage.haskell.org/package/capability. cc @aspiwack

[Arnaud Spiwack]

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)

[Ywen]

Yep, and the goal here is interoperability. A lot of libs have transitioned to unliftio, that's my original rationale.