I’ve released the first version of monad-unlift. From its README:
Typeclasses for providing for unlifting of monad transformers and stacks, and concrete implementations of common transformers implementing this type classes.
This package is a companion to monad-control, providing simplified functions to a common subset of transformers and functionality. I’ve copied in the content of the README below to give some examples and explanations.
I’d like to thank Erik Hesselink and Hiromi Ishii for providing some brilliant solutions to make this package more useful, based on the constraints package.
import Control.Concurrent.Async import Control.Monad.Trans.Unlift import Control.Monad.Trans.RWS.Ref import Control.Monad.IO.Class import Data.Mutable -- Some artbirary data type for the MonadReader data SomeEnv = SomeEnv Int myFunc :: RWSRefT -- The WriterT piece is contained by an IORef IORef -- For efficiency, we store the state in a primitive -- reference for efficiency (PRef RealWorld) SomeEnv -- Reader [String] -- Writer Int -- State IO (String, String) myFunc = do -- Get the unlift function. Due to weaknesses in ImpredicativeTypes, we -- need to use a newtype wrapper. You can also use askRunBase. -- -- If you want to just unwrap one transformer layer, use -- askUnlift/askRun/Unlift. UnliftBase run <- askUnliftBase -- Note that we can use unlift to turn our transformer actions into IO -- actions. Unlike the standard RWST, actions from separate threads are -- both retained due to mutable references. -- -- In real life: you shouldn't rely on this working, as RWST is not thread -- safe. This example is provided as a good demonstration of the type level -- functionality. liftIO $ concurrently (run foo) (run bar) where foo = do tell ["starting foo"] modify (+ 1) tell ["leaving foo"] return "foo is done" bar = do tell ["starting bar"] SomeEnv e <- ask modify (+ e) tell ["leaving bar"] return "bar is done" main :: IO () main = do ((w, x), y, z) <- runRWSRefT myFunc (SomeEnv 5) 6 print w -- foo is done print x -- bar is done print y -- 12 = 6 + 5 + 1 print z -- starting and leaving statements, order ambiguous
A common pattern is to have some kind of a monad transformer, and want to pass an action into a function that requires actions in a base monad. That sounds a bit abstract, so let’s give a concrete example:
-- From async concurrently :: IO a -> IO b -> IO (a, b) func1 :: ReaderT Foo IO String func2 :: ReaderT Foo IO Double doBoth :: ReaderT Foo IO (String, Double) doBoth = _
Doing this manually is possible, but a bit tedious:
doBoth :: ReaderT Foo IO (String, Double) doBoth = ReaderT $ foo -> concurrently (runReaderT func1 foo) (runReaderT func2 foo)
This also doesn’t generalize at all; you’ll be stuck writing
concurrently
variants for every monad transformer
stack. Fortunately, the monad-control
package
generalizes this to a large number of transformer stacks. Let’s
implement our generalized concurrently
:
concurrentlyG :: MonadBaseControl IO m => m a -> m b -> m (StM m a, StM m b) concurrentlyG f g = liftBaseWith $ run -> concurrently (run f) (run g)
Notice how, in the signature for concurrentlyG
, we
no longer return (a, b)
, but (StM m a, StM m
b)
. This is because there may be additional monadic context
for each thread of execution, and we have no way of merging these
together in general. Some examples of context are:
WriterT
, it’s the values that you called
tell
onEitherT
, the returned value may not exist at
allIn addition to this difficulty, many people find the types in
monad-control
difficult to navigate, due to their
extreme generality (which is in fact the power of that
package!).
There is a subset of these transformer stacks that are in fact
monad
morphisms. Simply stated, these are transformer stacks that are
isomorphic to ReaderT
. For these monads, there is not
context in the returned value. Therefore, there’s no need to
combine returned states or deal with possibly missing values.
This concept is represented by the monad-unlift package, which
provides a pair of typeclasses for these kinds of transformer
stacks. Before we dive in, let’s see how we solve our
concurrentlyG
problem with it:
concurrentlyG :: MonadBaseUnlift IO m => m a -> m b -> m (a, b) concurrentlyG f g = do UnliftBase run <- askUnliftBase liftBase $ concurrently (run f) (run g)
Notice how we get (a, b)
in the return type as
desired. There’s no need to unwrap values or deal with context.
MonadTransUnlift
is a class for any monad
transformer which is isomorphic to ReaderT
, in the
sense that the environment can be captured and applied later. Some
interesting cases in this space are:
IdentityT
and things isomorphic to it; in this
case, you can think of the environment as being
()
StateT
or WriterT
), but still obey
the monad morphism laws. (See below for more details.)Due to weaknesses in GHC’s ImpredicativeTypes, we have a helper
datatype to allow for getting polymorphic unlift functions,
appropriately named Unlift
. For many common cases, you
can get away with using askRun
instead, e.g.:
bar :: ReaderT Foo IO () baz :: ReaderT Foo IO () baz = do run <- askRun liftIO $ void $ forkIO $ run bar
Using Unlift
, this would instead be:
Unlift run <- askUnlift liftIO $ void $ forkIO $ run bar
or equivalently:
u <- askUnlift liftIO $ void $ forkIO $ unlift u bar
MonadBaseUnlift
extends this concept to entire
transformer stacks. This is typically the typeclass that people end
up using. You can think of these two typeclasses in exactly the
same way as MonadTrans
and MonadIO
, or
more precisely MonadTrans
and
MonadBase
.
For the same ImpredicativeTypes reason, there’s a helper type
UnliftBase
. Everything we just discussed should
transfer directly to MonadBaseUnlift
, so learning
something new isn’t necessary. For example, you can rewrite the
last snippet as:
u <- askUnliftBase liftIO $ void $ forkIO $ unliftBase u bar
When playing transformer stack games with a transformer like
StateT
, it’s common to accidentally discard state
modifications. Additionally, in the case of runtime exceptions,
it’s usually impossible to retain the state. (Similar statements
apply to WriterT
and RWST
, both in strict
and lazy variants.)
Another approach is to use a ReaderT
and hold onto
a mutable reference. This is problematic since there’s no built in
support for operations like get
, put
, or
tell
. What we want is to have a
MonadState
and/or MonadWriter
instance.
To address this case, this package includes variants of those
transformers that use mutable references. These reference are
generic using the mutable-containers
package, which allows you to have highly efficient references like
PRef
instead of always using boxed references like
IORef
.
Note that, for generality, the reference transformers take type parameters indicating which mutable reference type to use. Some examples you may use are:
IORef
for boxed references in IO
STRef s
for boxed references in
ST
PRef RealWorld
for an unboxed reference in
IO
See the synopsis for a complete example.
The transPipe
function in conduit has caused
confusion in the past due to its requirement of provided functions
to obey monad morphism laws. This package makes a good companion to
conduit to simplify that function’s usage.
Both the HandlerT
transformer from yesod-core and
LoggingT
/NoLoggingT
are valid monad
morphisms. HandlerT
is in fact my first example of
using the “enviornment holding a mutable reference” technique to
overcome exceptions destroying state.
{-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} import Control.Concurrent.Async import Control.Monad.IO.Class import Control.Monad.Logger import Control.Monad.Trans.Unlift main :: IO () main = runStdoutLoggingT foo foo :: (MonadLogger m, MonadBaseUnlift IO m, MonadIO m) => m () foo = do run <- askRunBase a <- liftIO $ async $ run $ $logDebug "Hello World!" liftIO $ wait a
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.