Functional programming treats a program as transformations of values rather than a sequence of commands that repeatedly changes shared state. In a pure functional style, intermediate results are defined once, then combined into larger definitions; a needed value can be evaluated from those definitions. This declarative view favors reusable pieces because a definition can be used in more than one context. section 1.2.1 section 1.2.2
Statelessness here means avoiding mutable variables: values are produced rather than modified over time. A pure function consumes its input and produces output without interacting with program state outside the function. It therefore cannot directly read or write files, network sockets, databases, memory, time, or random values. Effects still have to be performed, but pure Haskell controls them through design patterns, notably monadic programming. section 1.2.2 section 1.5
The philosophy changes several familiar design choices:
- Describe what results are, using composed and possibly recursive definitions, instead of prescribing every instruction in order. section 1.2.2
- Keep data immutable so that a name retains a clear definition instead of acquiring a different meaning after each update. section 1.2.1 section 1.2.2
- Pass functions as values, allowing transformations to be parameterized and supplied to other functions. section 1.2.2
- Replace some imperative habits, such as mutable variables, imperative control flow, and loops, with functional ways of expressing transformations. section 2.0
Recipes as value definitions
An imperative cake recipe says to melt, add, beat, mix, pour, and bake; each instruction depends on the kitchen’s changing state. A functional recipe instead defines a butter-and-chocolate mixture, a cake batter, a chocolate cake batter, and finally a chocolate cake. Each result is a named transformation or combination of earlier results. Changing from chocolate to lemon can then mean substituting a component rather than copying a long sequence of state-dependent steps. section 1.2.1 section 1.2.2
Purity is intended to make code safer, more composable, and easier to inspect: behavior follows from the inputs and definitions visible in the code rather than hidden external changes. The approach supports clean coding principles and is positioned for software ranging from small tools to data-oriented systems and web servers, while Haskell also supplies compilation, garbage collection, and support for parallelism and concurrency. section 1.5 section 1.0 section 1.1.1
