unliftIO -package:unliftio-core

The MonadUnliftIO typeclass for unlifting monads to IO (batteries included) Please see the documentation and README at https://www.stackage.org/package/unliftio

Please see the README.md file for information on using this package at https://www.stackage.org/package/unliftio.

This module presents the same interface as Control.Exception.Annotated, but uses MonadUnliftIO instead of MonadCatch or MonadThrow.

Data.Pool generalized to MonadUnliftIO. This is a generalization of Data.Pool to MonadUnliftIO.

UnliftIO using well-typed Paths. UnliftIO using well-typed Paths.

Not on Stackage, so not searched. Fast and robust message queues for concurrent processes

Generalization of io-streams to MonadUnliftIO Generalization of io-streams to MonadUnliftIO.

Not on Stackage, so not searched. Use MonadUnliftIO on servant APIs

Monads which allow their actions to be run in IO. While MonadIO allows an IO action to be lifted into another monad, this class captures the opposite concept: allowing you to capture the monadic context. Note that, in order to meet the laws given below, the intuition is that a monad must have no monadic state, but may have monadic context. This essentially limits MonadUnliftIO to ReaderT and IdentityT transformers on top of IO. Laws. For any function run provided by withRunInIO, it must meet the monad transformer laws as reformulated for MonadUnliftIO:

• run . return = return

• run (m >>= f) = run m >>= run . f

Instances of MonadUnliftIO must also satisfy the following laws:

• Identity law withRunInIO (\run -> run m) = m
• Inverse law withRunInIO (\_ -> m) = liftIO m

As an example of an invalid instance, a naive implementation of MonadUnliftIO (StateT s m) might be

withRunInIO inner =
StateT $ \s ->
withRunInIO $ \run ->
inner (run . flip evalStateT s)

This breaks the identity law because the inner run m would throw away any state changes in m.

Monads which allow their actions to be run in IO. While MonadIO allows an IO action to be lifted into another monad, this class captures the opposite concept: allowing you to capture the monadic context. Note that, in order to meet the laws given below, the intuition is that a monad must have no monadic state, but may have monadic context. This essentially limits MonadUnliftIO to ReaderT and IdentityT transformers on top of IO. Laws. For any value u returned by askUnliftIO, it must meet the monad transformer laws as reformulated for MonadUnliftIO:

• unliftIO u . return = return

• unliftIO u (m >>= f) = unliftIO u m >>= unliftIO
  u . f

Instances of MonadUnliftIO must also satisfy the idempotency law:

• askUnliftIO >>= \u -> (liftIO . unliftIO u) m =
  m

This law showcases two properties. First, askUnliftIO doesn't change the monadic context, and second, liftIO . unliftIO u is equivalent to id IF called in the same monadic context as askUnliftIO.

Create a local unlifting function with the given strategy along with an unrestricted lifting function. Useful for lifting complicated IO computations where the monadic action shows in both positive (as a result) and negative (as an argument) position. Note: depending on the computation you're lifting localUnliftIO along with withLiftMapIO might be enough and is more efficient.

Create a local unlifting function with the SeqUnlift strategy. For the general version see localUnliftIO.

Create a local unlifting function with the given strategy.

Create an unlifting function with the ConcUnlift strategy.

Create an unlifting function with the SeqUnlift strategy.

Create an unlifting function with the ConcUnlift strategy. This function is unsafe because it can be used to introduce arbitrary IO actions into pure Eff computations.

Create an unlifting function with the SeqUnlift strategy. This function is unsafe because it can be used to introduce arbitrary IO actions into pure Eff computations.

Create an unlifting function. This function is really unsafe because:

• It can be used to introduce arbitrary IO actions into pure Eff computations.
• Unlifted Eff computations must be run in a way that's perceived as sequential to the outside observer, e.g. in the same thread as the caller of reallyUnsafeUnliftIO or in a worker thread that finishes before another unlifted computation is run.

Warning: if you disregard the second point, you will experience weird bugs, data races or internal consistency check failures. When in doubt, use unsafeSeqUnliftIO, especially since this version saves only a simple safety check per call of the unlifting function.

Create an unlifting function with the SeqForkUnlift strategy.

Monads which allow their actions to be run in IO. While MonadIO allows an IO action to be lifted into another monad, this class captures the opposite concept: allowing you to capture the monadic context. Note that, in order to meet the laws given below, the intuition is that a monad must have no monadic state, but may have monadic context. This essentially limits MonadUnliftIO to ReaderT and IdentityT transformers on top of IO. Laws. For any value u returned by askUnliftIO, it must meet the monad transformer laws as reformulated for MonadUnliftIO:

• unliftIO u . return = return

• unliftIO u (m >>= f) = unliftIO u m >>= unliftIO
  u . f

The third is a currently nameless law which ensures that the current context is preserved.

• askUnliftIO >>= (u -> liftIO (unliftIO u m)) =
  m

If you have a name for this, please submit it in a pull request for great glory.

Capture the current monadic context, providing the ability to run monadic actions in IO. See UnliftIO for an explanation of why we need a helper datatype here.

Derive HasError using the functionality from the unliftio package.