Control.Monad.Accum (original) (raw)

Computation type:

Accumulation (either append-only state, or writer with the ability to read all previous input).

Binding strategy:

Binding a function to a monadic value monoidally accumulates the subcomputations (that is, using [<>](/package/base-4.16.3.0/docs/Data-Monoid.html#v:-60--62- "Data.Monoid")).

Useful for:

Logging, patch-style tracking.

Zero and plus:

None.

Example type:

`[Accum](/package/transformers-0.5.6.2/docs/Control-Monad-Trans-Accum.html#v:Accum "Control.Monad.Trans.Accum")` w 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](Control-Monad-Reader.html#t:ReaderT "Control.Monad.Reader") and[StateT](Control-Monad-State-Strict.html#t:StateT "Control.Monad.State.Strict") respectively. If we have`[ReaderT](Control-Monad-Reader.html#t:ReaderT "Control.Monad.Reader")` r (`[State](Control-Monad-State-Strict.html#t:State "Control.Monad.State.Strict")` s) a, this is effectively r -> `[State](Control-Monad-State-Strict.html#t:State "Control.Monad.State.Strict")` s a ~ r -> s -> (a, s); if we instead have`[StateT](Control-Monad-State-Strict.html#t:StateT "Control.Monad.State.Strict")` s (`[Reader](/package/transformers-0.5.6.2/docs/Control-Monad-Trans-Reader.html#v:Reader "Control.Monad.Trans.Reader")` r) a, this is effectivelys -> `[Reader](Control-Monad-Trans.html#v:Reader "Control.Monad.Trans")` r (a, s) ~ s -> r -> (a, s). Since we can always reorder function arguments (for example, using [flip](/package/base-4.16.3.0/docs/Data-Function.html#v:flip "Data.Function"), 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](/package/transformers-0.5.6.2/docs/Control-Monad-Trans-Maybe.html#t:MaybeT "Control.Monad.Trans.Maybe") and [StateT](Control-Monad-State-Strict.html#t:StateT "Control.Monad.State.Strict") respectively. If we have `[MaybeT](/package/transformers-0.5.6.2/docs/Control-Monad-Trans-Maybe.html#t:MaybeT "Control.Monad.Trans.Maybe")` (`[State](/package/transformers-0.5.6.2/docs/Control-Monad-Trans-State-Strict.html#v:State "Control.Monad.Trans.State.Strict")` s) a, this is effectively `State` s (`[Maybe](/package/base-4.16.3.0/docs/Data-Maybe.html#t:Maybe "Data.Maybe")` a) ~ s -> (`[Maybe](/package/base-4.16.3.0/docs/Data-Maybe.html#t:Maybe "Data.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](Control-Monad-State-Strict.html#t:StateT "Control.Monad.State.Strict")` s `[Maybe](/package/base-4.16.3.0/docs/Data-Maybe.html#t:Maybe "Data.Maybe")` a, this is instead s -> `[Maybe](/package/base-4.16.3.0/docs/Data-Maybe.html#t:Maybe "Data.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](Control-Monad-State-Class.html#v:MonadState "Control.Monad.State.Class"), for example, whether your final monadic stack ends up being `[MaybeT](/package/transformers-0.5.6.2/docs/Control-Monad-Trans-Maybe.html#t:MaybeT "Control.Monad.Trans.Maybe")` (`[State](/package/transformers-0.5.6.2/docs/Control-Monad-Trans-State-Strict.html#v:State "Control.Monad.Trans.State.Strict")` s) a, `[StateT](Control-Monad-State-Strict.html#t:StateT "Control.Monad.State.Strict")` s `[Maybe](/package/base-4.16.3.0/docs/Data-Maybe.html#t:Maybe "Data.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 accumulation

The accumulation effect commutes with the identity effect ([IdentityT](/package/transformers-0.5.6.2/docs/Control-Monad-Trans-Identity.html#t:IdentityT "Control.Monad.Trans.Identity")), reader, writer or state effects ([ReaderT](Control-Monad-Reader.html#t:ReaderT "Control.Monad.Reader"), [WriterT](Control-Monad-Writer-Strict.html#t:WriterT "Control.Monad.Writer.Strict"), [StateT](Control-Monad-State-Strict.html#t:StateT "Control.Monad.State.Strict") and any combination, including [RWST](Control-Monad-RWS-Strict.html#t:RWST "Control.Monad.RWS.Strict") for example) and with itself. It does not commute with anything else.