extensible-effects- An Alternative to Monad Transformers

Safe HaskellTrustworthy



Strict state effect



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.

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

The conventional design of State


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 #

runState Source #


:: 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



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.