Control.Eff.State.Lazy

State, lazy

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

Embed a pure value in a stateful computation, i.e., given an initial state, how to interpret a pure value in a stateful computation.

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

Write a new value of the state.

Run a State effect

Transform the state with a function.

Run a State effect, discarding the final state.

Run a State effect and return the final state.

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

Embed Transactional semantics to a stateful computation.

Confer transactional semantics on a stateful computation.

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.