> 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.
> Continuation-based monads cannot have instances of MonadUnliftIO, the same as MonadBaseControl and MonadMask.
Then I'm not sure `Snap`'s `MonadBaseControl` instance shall really work.
>
> The main contention until now is that unlifting in a transformer like
> `StateT` is unsafe. This is not universally true: if only one action
> is being unlifted, no ambiguity exists. So, for example, `try :: IO a
> -> IO (Either e a)` can safely be unlifted in `StateT`, while `finally
> :: IO a -> IO b -> IO a` cannot.
>
> `monad-control` allows us to unlift both styles. In theory, we could
> write a variant of `lifted-base` that never does state discards, and
> let `try` be more general than `finally`. In other words, this is an
> advantage of `monad-control` over `MonadUnliftIO`. We've avoided
> providing any such extra typeclass in this package though, for two
> reasons:
>
> * `MonadUnliftIO` is a simple typeclass, easy to explain. We don't
> want to complicated matters (`MonadBaseControl` is a notoriously
> difficult to understand typeclass). This simplicity
> is captured by the laws for `MonadUnliftIO`, which make the
> behavior of the run functions close to that of the already familiar
> `lift` and `liftIO`.
> * Having this kind of split would be confusing in user code, when
> suddenly `finally` is not available to us. We would rather encourage
> from the beginning.
>
> Another distinction is that `monad-control` uses the `MonadBase`
> style, allowing unlifting to arbitrary base monads. In this package,
> we've elected to go with `MonadIO` style. This limits what we can do
> (e.g., no unlifting to `STM`), but we went this way because:
>
> * In practice, we've found that the vast majority of cases are dealing
> with `IO`
> * The split in the ecosystem between constraints like `MonadBase IO`
> and `MonadIO` leads to significant confusion, and `MonadIO` is by
> far the more common constraints (with the typeclass existing in
> `base`)
>
So is `MonadBaseControl` dead or alive? Any user side example for it?