14 Local effects and mutable state

 

This chapter covers

  • Defining referential transparency in terms of mutable state
  • Hiding local state change through typed scoping of effects
  • Developing a domain-specific language (DSL) to encapsulate mutable state
  • Establishing an algebra and interpreter for running programs

In chapter 1, we introduced the concept of referential transparency, setting the premise for purely functional programming. We declared that pure functions can’t mutate data in place or interact with the external world. In chapter 13, we learned that this isn’t exactly true. We can write purely functional and compositional programs that describe interactions with the outside world. These programs are unaware that they can be evaluated with an interpreter that has an effect on the world.

14.1 State mutation is legal in pure functional code

14.2 A data type to enforce scoping of side effects

14.2.1 A domain-specific language for scoped mutation

14.2.2 An algebra of mutable references

14.2.3 Running mutable state actions

14.2.4 The mutable array represented as a data type for the ST monad

14.2.5 A purely functional in-place quicksort

14.3 Purity is contextual

14.3.1 Definition by example

14.3.2 What counts as a side effect?

Summary