mtl-2.3.1: Monad classes for transformers, using functional dependencies

Contents

Description

Computation type:
Backtracking search, with r as a 'ranking' or 'evaluation' type.
Binding strategy:
Binding a function to a monadic value 'chains together' strategies; having seen the result of one search, decide which policy to use to continue.
Useful for:
Search problems.
Zero and plus:
None.
Example type:
Select r a

# A note on commutativity

Some effects are commutative: it doesn't matter which you resolve first, as all possible orderings of commutative effects are isomorphic. Consider, for example, the reader and state effects, as exemplified by ReaderT and StateT respectively. If we have ReaderT r (State s) a, this is effectively r -> State s a ~ r -> s -> (a, s); if we instead have StateT s (Reader r) a, this is effectively s -> Reader r (a, s) ~ s -> r -> (a, s). Since we can always reorder function arguments (for example, using flip, as in this case) without changing the result, these are isomorphic, showing that reader and state are commutative, or, more precisely, commute with each other.

However, this isn't generally the case. Consider instead the error and state effects, as exemplified by MaybeT and StateT respectively. If we have MaybeT (State s) a, this is effectively State s (Maybe a) ~ s -> (Maybe a, s): put simply, the error can occur only in the result, but not the state, which always 'survives'. On the other hand, if we have StateT s Maybe a, this is instead s -> Maybe (a, s): here, if we error, we lose both the state and the result! Thus, error and state effects do not commute with each other.

As the MTL is capability-based, we support any ordering of non-commutative effects on an equal footing. Indeed, if you wish to use MonadState, for example, whether your final monadic stack ends up being MaybeT (State s) a, StateT s Maybe a, or anything else, you will be able to write your desired code without having to consider such differences. However, the way we implement these capabilities for any given transformer (or rather, any given transformed stack) is affected by this ordering unless the effects in question are commutative.

We note in this module which effects the accumulation effect does and doesn't commute with; we also note on implementations with non-commutative transformers what the outcome will be. Note that, depending on how the 'inner monad' is structured, this may be more complex than we note: we describe only what impact the 'outer effect' has, not what else might be in the stack.

# Commutativity of selection

The selection effect commutes with the identity effect (IdentityT), but nothing else.

Synopsis

# Type class

class Monad m => MonadSelect r (m :: Type -> Type) | m -> r where Source #

The capability to search with backtracking. Essentially describes a 'policy function': given the state of the search (and a 'ranking' or 'evaluation' of each possible result so far), pick the result that's currently best.

# Laws

Since: mtl-2.3

Methods

select :: ((a -> r) -> a) -> m a Source #

#### Instances

Instances details

# Lifting helper type

newtype LiftingSelect (t :: (Type -> Type) -> Type -> Type) (m :: Type -> Type) a Source #

A helper type to decrease boilerplate when defining new transformer instances of MonadSelect.

Most of the instances in this module are derived using this method; for example, our instance of ExceptT is derived as follows:

deriving via (LiftingSelect (ExceptT e) m) instance (MonadSelect r m) =>