State is the information a computation uses to represent its current condition and influence later behavior. Treat it as a design concern rather than merely a variable: its lifetime, visibility, ownership, and relationship to effects determine how safely an application evolves. Functional programs can be stateful without abandoning immutability; the central task is to keep state and side effects from spreading through business logic. section 7.0 section 7.1
Classify state first by how long it must live, then by how it is handled:
- Local or auxiliary state exists for one calculation, remains invisible outside it, and can be discarded when that calculation ends. section 7.1
- Operational state lasts roughly as long as the application and drives business logic or retains important user-defined data. section 7.1
- External state outlives the application and resides in long-term storage such as databases. section 7.1
- Pure state models change without destroying the prior value. Argument passing carries an updated value forward; a state monad packages that flow in a monadic context. section 7.1 section 7.3
- Impure state updates memory, files, databases, or mutable variables through side effects. It can be appropriate in implementation code, but requires explicit control of nondeterminism and concurrency hazards. section 7.1 section 7.2.4
Threading an updated spaceship model
An immutable model can still describe a changing spaceship. A rotation operation reads the current mass, calculates an impulse, recalculates mass, then uses the new mass for the next burn. Each step returns a new model or properties value, making the progression visible: value → use value → updated value. This keeps the changing business state in function inputs and results instead of hiding it in a mutable cell. section 7.2.1
Separating recipe logic from kitchen state
A sandwich script describes business operations through eDSL interfaces, while an interpreter consumes ingredients held in an IORef and produces the finished sandwich. The application layer joins script, interpreter, and operational state. This separation lets business logic remain independent of the mutable implementation used to execute it. section 7.1.1 section 7.2.4
Runtime state often belongs to an interpreter rather than a scenario or script. A controller name can be a lightweight value in the script while its implementation exists only at runtime. When many devices may be active, a Runtime can hold a map of devices addressed by controllers; lifetime decisions then determine whether instances survive after a script ends or are destroyed with its scope. section 5.3 section 5.3.1
Figure 7.2 A layered free monadic architecture
The layered architecture diagram makes the boundary visible: business scripts, interpreters, operational state, and the application layer have distinct responsibilities. section 7.1.1
