liveBook · Manning

Side effect

As explained in F# in Action: A Revised Edition of Get Programming with F#

A side effect is an observable change or interaction caused by a function beyond producing its return value, such as modifying external data or state.

A side effect is an observable change or interaction beyond a function’s return value. Writing a database row, changing global mutable state, printing to the console, or saving a file are side effects. Because they are not visible in a function’s inputs and outputs, they can make behavior harder to inspect and test. section 4.1.1 section 4.1.6

A pure function instead depends only on its arguments and returns its result directly. Repeating it with the same inputs gives the same output. Moving state through return values makes each transition explicit, rather than hiding a change inside an object or global variable. section 4.2.3 section 14.3.1

Use these practical cues when reading F# function signatures:

  • Treat unit input, (), as a hint that each call may observe changing world state, such as the current time or a random value. section 4.1.6
  • Treat unit output as a hint that the final action performs I/O, such as console output, file writing, or database saving. section 4.1.6
  • Do not rely on unit as proof: F# permits side effects in functions whose signatures do not contain unit. section 4.1.6

Make state changes visible

A mutable drive function can change a shared gas value without returning it. An immutable version accepts gas and distance, returns updated gas, and passes that result into the next call. The latter exposes intermediate states, supports repeatable calls, and gives tests a direct input-and-output shape. section 4.2.3 section 4.2.2

Prefer pure functions for ordinary logic where practical, then isolate unavoidable interactions such as database access in focused boundaries. Tests for pure code can create inputs, call a function, and assert its returned value; tests involving effects may need to inspect changed object behavior or external data. section 4.1.1 section 14.3.1

The word effect can also describe a wrapper that carries behavior around data, such as Option, Result, Task, or a collection. That use is managed with operations such as map and bind or computation expressions; it is distinct from an external state change, though pure calculation functions can be kept free of such wrappers. section 9.3 section 15.4.2

How F# in Action: A Revised Edition of Get Programming with F# covers it

How deep it goes
Defines external changes, identifies unit as an imperfect signature clue, and compares mutable state with explicit immutable transitions.
Examples
Uses salary updates, customer saving, time lookup, console printing, database writes, and a gas-driving state model.
What it assumes
Introduces purity and side effects directly without assuming prior F# or .NET knowledge.
What you can do after
Evaluate/understand whether behavior is hidden in external changes or expressed through inputs and returned state.
How it connects
Connects purity, mutable state, immutable data, unit, computation expressions, Option, Result, Task, map, and bind.

Also explained in

Compare how 24 books explain side effect →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of F# in Action: A Revised Edition of Get Programming with F#. The section links point to the parts of the book it draws on.