nw-fp-principles

FP Principles

Core functional programming thinking patterns. Language-agnostic.

Cross-references: fp-domain-modeling | fp-hexagonal-architecture | fp-algebra-driven-design

---

1. Higher-Order Functions as Problem Decomposition

[STARTER]

Three operations replace most loops:

Operation	Purpose	Replaces
Map	Transform each element, preserve structure	Loop building new collection
Filter	Keep elements matching condition	Loop with conditional
Fold	Accumulate elements into single result	Loop with running total

When to use Map: Transform every element without changing collection shape. Nested maps handle nested structures. When to use Filter: Select elements without changing their values. When to use Fold: Reduce collection to single value. Accumulator IS your state. Combining function IS your state transition. Folds make state machines explicit.

Decision: "Am I transforming, selecting, or accumulating?" Pick matching operation. If none fit, compose two.

Why: These operations communicate intent. Map says "same shape, different values." Fold says "many inputs, one output." Loops say nothing about intent until you read every line.

---

2. Type-Driven Design

[STARTER]

Write the type signature before implementation. The type tells you what the function can and cannot do.

Process:

1. Declare what the function consumes and produces
2. Ask: "which type-specific operations do I actually use?"
3. Replace concrete types with type variables for everything you don't inspect
4. Add constraints only for capabilities you use (equality, ordering, display)

Design progression: Concrete types -> type variables -> constrained type variables. Each step increases reuse while documenting minimal assumptions.

Why: Function's type signature is a contract. Narrower types mean fewer possible implementations, fewer bugs.