fused-effects / fused-effects

A fast, flexible, fused effect system for Haskell

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Elaborate on how `Lift` removes the need for `MonadUnliftIO`

ilyakooo0 opened this issue · comments

commented

It is not quite clear from the docs what to do if a library has a function, which is run in a MonadUnliftIO monad. How to call that function given that there is a Lift IO in the stack?

I wonder if we can have newtype FusedUnliftIO m wrapper with Has (Lift IO) m => MonadUnliftIO m.

You can't implement withRunInIO using Lift IO; liftWith simply isn't powerful enough to do that.

This is ultimately because you can't impose any constraints upon the functorial state f in a liftWith (because the weave abstraction won't allow it). You can't, for example, say "this must be Identity". polysemy extends the weave abstraction with an ugly, but useful hack to mitigate this issue, which as a side-effect makes polysemy's corresponding effect to Lift (Final) more powerful than Lift; but still not powerful enough to represent a MonadUnliftIO effect.

I think it should be possible to find a more elegant solution to this in a carrier-based solution like fused-effects, but it would replacing or overhauling the weave abstraction which is fine, it's pretty trash anyway.

We’re adding a MonadUnliftIO instance soon, so we can nix this.