Control.Eff.State.Strict

Strict state effect

Documentation

data State s v where

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.

See also below, for decomposing the State into Reader and Writer!

The conventional design of State

Constructors

Get :: State s s

Put :: !s -> State s ()

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

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

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

Write a new value of the state.

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

runState

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 ()

Transform the state with a function.

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

Run a State effect, discarding the final state.

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

Run a State effect and return the final state.

data ProxyState s

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

Constructors

ProxyState

transactionState :: forall s r w. Member (State s) r => ProxyState s -> Eff r w -> Eff r w

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

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.