In what situations should liftIO
be used? When I'm usi开发者_Python百科ng ErrorT String IO
, the lift
function works to lift IO actions into ErrorT
, so liftIO
seems superfluous.
lift
always lifts from the "previous" layer. If you need to lift from the second layer, you would need lift . lift
and so on.
On the other hand, liftIO
always lifts from the IO layer (which, when present, is always on the bottom of the stack). So, if you have more than 2 layers of monads, you will appreciate liftIO
.
Compare the type of the argument in the following lambdas:
type T = ReaderT Int (WriterT String IO) Bool
> :t \x -> (lift x :: T)
\x -> (lift x :: T) :: WriterT String IO Bool -> T
> :t \x -> (liftIO x :: T)
\x -> (liftIO x :: T) :: IO Bool -> T
liftIO is just a shortcut to the IO Monad, whichever the Monad you are in. Basically, liftIO equals to using a variable number of lifts. At first this might sound redundant but using liftIO has one big advantage: it makes your IO code indpendent of the actual Monad construction so you can reuse the same code no matter the number of layer your final Monad has been built of (this is quite important when writing a monad transformer).
On the ohter hand, liftIO is not coming for free, as lift does: the Monad transformers you're using must have support for it, e.g. the Monad you're in must be an instance of the MonadIO class, but most Monads nowadays do (and of course, the type-checker will check this for you at compile time: that's the strength of Haskell!).
Previous answers all explain the difference quite well. I just wanted to shed a some light on the inner workings so that it could be easier to understand how liftIO
isn't something magical (for the novice Haskellers like me).
liftIO :: IO a -> m a
is a wise tool just build upon
lift :: (Control.Monad.Trans.Class.MonadTrans t, Monad m) => m a -> t m a
and most often used when the bottom monad is IO
. For the IO
monad it's definition is quite simple.
class (Monad m) => MonadIO m where
liftIO :: IO a -> m a
instance MonadIO IO where
liftIO = id
That simple... liftIO
is in fact just id
for the IO
monad and basically IO
is the only one that comes within the definition of the type class.
The thing is, when we have a monad type which is composed of several layers of monad transformers over IO
, we better have an MonadIO
instance for each one of those monad transformer layers. For example the MonadIO
instance of MaybeT m
requires m
to be of MonadIO
typeclass as well.
Writing a MonadIO
instance is basically a very simple task too. For MaybeT m
it is defined like
instance (MonadIO m) => MonadIO (MaybeT m) where
liftIO = lift . liftIO
or for StateT s m
instance (MonadIO m) => MonadIO (StateT s m) where
liftIO = lift . liftIO
they are all the same. Imagine when you have a 4 layer transformer stack then you either need to do lift . lift . lift . lift $ myIOAction
or just liftIO myIOAction
. If you think about it, every lift . liftIO
will take you one layer down in the stack up until it digs all the way down to IO
at where liftIO
is defined as id
and finalizes with the same code like composed lift
s above.
So this is basically why regardless of the transformer stack configuration, provided that all underlaying layers are members of MonadIO
and MonadTrans
a single liftIO
is just fine.
精彩评论