Finite-State Machines
Stateful programs often become complex beasts when they grow. Program state incohesively spread across a bunch of variables, spuriously guarded by even more variables, is what I refer to as implicit state. When working with such code, we have to reconstruct a model mentally, identifying possible states and transitions between them, to modify it with any certainty. That process is tedious and error-prone, and I insist we should have our tools do the heavy lifting instead.
This is a series of post based on the subject of using expressive type systems and functional programming to encode finite-state machines.
-
Finite-State Machines, Part 2: Explicit Typed State Transitions
In the second post of the Finite-State Machines series, we improve type safety around state transitions and their side effects, and make testing state machines without side effects easier, using an extended MTL style encoding.
-
Finite-State Machines, Part 1: Modeling with Haskell Data Types
Stateful programs often become complex beasts as they grow. This is the first post in a series about teaching the type system about possible states and state transitions in our programs.