Propagating MonadIO constraint downwards about fused-effects HOT 3 CLOSED

Lift IO gives Eff a MonadIO instance, but runM takes Eff (LiftC m) a -> m a, and not e.g. MonadIO m => Eff (LiftC IO) a -> m a. Therefore, since runM should return in IO, you’ll need to add another liftIO at the outside:

doliftio :: MonadIO m => m ()
doliftio = liftIO (runM (liftIO (putStrLn "hello")))

or equivalently, change the type of doliftio to IO:

doliftio :: IO ()
doliftio = runM (liftIO (putStrLn "hello"))

from fused-effects.

A closely related question is why we only provide a MonadIO instance for Lift IO and not for e.g. MonadIO m => Lift m, and it’s basically down to ambiguity; the ergonomics are much worse if using liftIO in an Eff context doesn’t fix the type of m to IO, because the type checker would essentially have to guess m at every point where you’re using liftIO.

I’m hoping that we’ll be able to resolve this a little more like typical monad transformer stacks where the MonadIO instance for Eff m depends on a MonadIO instance for m, but as carriers are not, in general, Monads right now, we’ll have to play that one by ear.

from fused-effects.

I’m going to close this out now, tho the related issue of Lift IO being less useful in practice than MonadIO m => Lift m is still in play, and I’ll file an issue about it.

from fused-effects.