functional-composing-functionslisted

# Composing Functions ## Overview Functional design builds behaviour by connecting small functions, and connecting them works only when each one is **total**: for every input of the declared type it produces an output of the declared type, with no exception, no null, and no hidden condition. Totality is what makes composition safe; without it every join is a place where the chain can silently break. The rest is mechanics: composition, pipes, currying, and partial application. They are worth knowing precisely, because they are how dependencies are supplied and how pipelines are assembled. ## When to use - Two functions almost fit but not quite - Deciding the order of a function's parameters - A function throws for some inputs, or returns null - Building a pipeline out of existing functions - Wondering whether to pass a value or a function Not for: designing the domain types themselves. ## Core rules 1. Rule. **Make every function total.** Narrow the input type, or widen the output type to `Option` or `Result`. Never leave the gap implicit. 2. Judgement. **One input, one output, conceptually.** Group related parameters into a named record rather than passing six positional arguments. 3. Default. **Put the varying argument last.** Data last, configuration and dependencies first, so partial application produces a useful function. 4. Default. **Name the composed function.** A pipeline assigned to a name that states the business process beats a long anonymous ch