extensible-effects-2.4.0.0: An Alternative to Monad Transformers

Control.Eff.State.Strict

Description

Strict state effect

Synopsis

# Documentation

data State s v where Source #

State, strict

Initial design: The state request carries with it the state mutator function We can use this request both for mutating and getting the state. But see below for a better design!

data State s v where
State :: (s->s) -> State s s

In this old design, we have assumed that the dominant operation is modify. Perhaps this is not wise. Often, the reader is most nominant.

The conventional design of State

Constructors

 Get :: State s s Put :: !s -> State s ()

get :: Member (State s) r => Eff r s Source #

Return the current value of the state. The signatures are inferred

put :: Member (State s) r => s -> Eff r () Source #

Write a new value of the state.

runState' :: Eff (State s ': r) w -> s -> Eff r (w, s) Source #

Arguments

 :: Eff (State s ': r) w Effect incorporating State -> s Initial state -> Eff r (w, s) Effect containing final state and a return value

Run a State effect

modify :: Member (State s) r => (s -> s) -> Eff r () Source #

Transform the state with a function.

evalState :: Eff (State s ': r) w -> s -> Eff r w Source #

Run a State effect, discarding the final state.

execState :: Eff (State s ': r) w -> s -> Eff r s Source #

Run a State effect and return the final state.

data TxState s Source #

An encapsulated State handler, for transactional semantics The global state is updated only if the transactionState finished successfully

Constructors

 TxState

transactionState :: forall s r w. Member (State s) r => TxState s -> Eff r w -> Eff r w Source #

runStateR :: Eff (Writer s ': (Reader s ': r)) w -> s -> Eff r (w, s) Source #

A different representation of State: decomposing State into mutation (Writer) and Reading. We don't define any new effects: we just handle the existing ones. Thus we define a handler for two effects together.