Propagating MonadIO constraint downwards

[deepfire]

How does one use the underlying monad that is MonadIO-constrained using runM?

On the first approach it doesn't work (full exhibit at [1]):

doliftio :: MonadIO m => m ()
doliftio = runM (liftIO $ putStr "")

..yields..

test/Control/Effect/LiftIO.hs:26:18: error:
    ⢠Could not deduce (Member (Lift IO) (Lift m))
        arising from a use of âliftIOâ
      from the context: MonadIO m
        bound by the type signature for:
                   doliftio :: forall (m :: * -> *). MonadIO m => m ()
        at test/Control/Effect/LiftIO.hs:25:1-29
    ⢠In the first argument of ârunMâ, namely â(liftIO $ putStr "")â
      In the expression: runM (liftIO $ putStr "")
      In an equation for âdoliftioâ: doliftio = runM (liftIO $ putStr "")
   |
28 | doliftio = runM (liftIO $ putStr "")
   |                  ^^^^^^^^^^^^^^^^^^

--

1. https://github.com/deepfire/fused-effects/blob/2a10f9351d8602b6c32b7af8830d58c76dad0655/test/Control/Effect/LiftIO.hs

[robrix]

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"))

[robrix]

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.

[robrix]

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.