A pure function always returns the same output for the same inputs and has no observable side effects. Its result depends only on arguments, not on hidden global state, private mutable fields, file writes, or database changes. That makes the function’s behavior visible as a simple input-to-output contract. section 4.1.1 section 14.3.1
Use purity to model state changes as values rather than mutations. A driving function can accept the current gas and distance, then return updated gas; callers explicitly pass that returned value into the next step. Each intermediate state is inspectable, calls are repeatable, and ordering dependencies are clear. section 4.2.3
Pure functions are especially useful when you want code that is easy to reason about and test:
- Test by arranging input values, calling the function, and asserting its returned result rather than inspecting changed object state or external systems. section 4.1.1 section 14.3.1
- Reuse and cache computations whose results depend solely on supplied data. section 15.2.3
- Separate data generation from external behavior: return text from one function, then let another function print it. section 15.2.3
Keep console output at the edge
For customer messaging, make a function such as describeCustomer return a greeting string. A separate describeToConsole function can pass that string to a console printer. The string-producing logic remains independently testable; the console-writing wrapper is the deliberately impure boundary. section 15.2.3 section 15.2.4
Listing 4.7 Managing state with immutable values
let drive gas distance = #1
if distance = "far" then gas / 2.0
elif distance = "medium" then gas – 10.0
else gas – 1.0
let gas = 100.0 #2
let firstState = drive gas "far" #3
let secondState = drive firstState "medium"
let finalState = drive secondState "near" #4
Compare mutable gas updates with an immutable drive function that receives gas and returns the next state for explicit chaining. section 4.2.3
