The Eff monad provides the implementation of a computation that performs an arbitrary set of effects. In Eff es a, es is a type-level list that contains all the effects that the computation may perform. For example, a computation that produces an Integer by consuming a String from the global environment and acting upon a single mutable value of type Bool would have the following type:

(Reader String :> es, State Bool :> es) => Eff es Integer

Abstracting over the list of effects with (:>):

• Allows the computation to be used in functions that may perform other effects.
• Allows the effects to be handled in any order.

The kind of effects.

A type of dispatch. For more information consult the documentation in Effectful.Dispatch.Dynamic and Effectful.Dispatch.Static.

Dispatch types of effects.

A constraint that requires that a particular effect e is a member of the type-level list es. This is used to parameterize an Eff computation over an arbitrary list of effects, so long as e is somewhere in the list.

For example, a computation that only needs access to a mutable value of type Integer would have the following type:

State Integer :> es => Eff es ()

Convenience operator for expressing that a function uses multiple effects in a more concise way than enumerating them all with (:>).

[E1, E2, ..., En] :>> es ≡ (E1 :> es, E2 :> es, ..., En :> es)

Run a pure Eff computation.

For running computations with side effects see runEff.

Run an Eff computation with side effects.

For running pure computations see runPureEff.

Run arbitrary IO computations via MonadIO or MonadUnliftIO.

Note: it is not recommended to use this effect in application code as it is too liberal. Ideally, this is only used in handlers of more fine-grained effects.

Lift an Eff computation into an effect stack with one more effect.

Eliminate a duplicate effect from the top of the effect stack.

Allow for running an effect stack xs within es as long as xs is a permutation (with possible duplicates) of a subset of es.

Generalizes raise and subsume.

Note: this function should be needed rarely, usually when you have to cross API boundaries and monomorphic effect stacks are involved. Using monomorphic stacks is discouraged (see Eff), but sometimes might be necessary due to external constraints.

Provide evidence that xs is a subset of es.

The strategy to use when unlifting Eff computations via withEffToIO, withRunInIO or the localUnlift family.

Warning: unlifting functions should not be used outside of continuations that brought them into scope. The behavior when doing so is undefined.

Persistence setting for the ConcUnlift strategy.

Different functions require different persistence strategies. Examples:

• Lifting pooledMapConcurrentlyN from the unliftio library requires the Ephemeral strategy as we don't want jobs to share environment changes made by previous jobs run in the same worker thread.
• Lifting forkIOWithUnmask requires the Persistent strategy, otherwise the unmasking function would start with a fresh environment each time it's called.

Limit setting for the ConcUnlift strategy.

Get the current UnliftStrategy.

Locally override the UnliftStrategy with the given value.

Create an unlifting function with the current UnliftStrategy.

This function is equivalent to withRunInIO, but has a HasCallStack constraint for accurate stack traces in case an insufficiently powerful UnliftStrategy is used and the unlifting function fails.

Monads in which IO computations may be embedded. Any monad built by applying a sequence of monad transformers to the IO monad will be an instance of this class.

Instances should satisfy the following laws, which state that liftIO is a transformer of monads:

• liftIO . return = return

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