There's a programming heuristic that most experienced developers absorb through osmosis: move your branching logic toward the caller, and push your loops toward the inner engine. TigerBeetle's Tiger Style document codifies it. matklad blogged about it. But this post does something different — it asks why the heuristic works, and it finds the answer in the algebra. The core move is clean. If a function takes Option and branches internally, you're smuggling a decision into the callee. Push the if up: the caller handles the None case, the callee takes a plain Walrus, and the type system enforces the precondition. The function's signature now tells you what it won't do. For the loop direction, the logic inverts — instead of calling frobnicate per element, you hand a batch to frobnicatebatch and let the tight inner loop run branch-free, a candidate for vectorization. The two compose: filter out the Nones, collect a Vec , hand it to the batch function. No branch in the hot path. The database parallel is where the post earns its keep. SQL query optimizers do exactly this — push selections and projections down the plan tree so they execute early (reducing data volume before expensive joins), and defer joins until inputs are minimal. The vocabulary inverts because data flows up from leaf scans to root, but the structural logic is identical: filter early, combine late. The post also draws the line from row-at-a-time Volcano execution to vectorized batch processing — the same frobnicate-versus-frobnicatebatch distinction, running inside a query engine. Then comes the category theory. Option is the coproduct 1 + Walrus. A function out of a coproduct is a pair of functions, one per summand. Pushing the if up factors that pair apart. The caller handles the trivial summand, the callee handles the real one. The subobject framing is elegant: the predicate-satisfying subset with its inclusion monomorphism is exactly the narrowed type. The callee operates on the subobject and never sees elements that don't belong. The filter-before-map analysis is the most technically honest section. The post proves filter p . map f == map f . filter (p . f) via the naturality of catMaybes, and then immediately notes the constraint: the rewrite only saves work when p . f simplifies to a cheap predicate on the input, typically because p inspects a part of the value that f leaves alone. Both sides are O(n). You save f-calls on discarded elements, not asymptotic complexity. This is the kind of precision that separates a useful heuristic from a cargo-cult rule. The summary lands the key insight: these aren't just style preferences. They're algebraic rewrites with preconditions. Taking an if out of a loop requires the condition to be loop-invariant. Pushing a selection below a join requires the predicate to reference only one side. Filter-before-map requires the composition p . f to collapse cheaply. The algebra tells you which rewrites are legal. Naturality of catMaybes isn't decoration — it's the proof obligation. What the post doesn't do is benchmark anything, profile real code, or show where the heuristic breaks catastrophically in production. It's a conceptual unification piece, not an empirical one. That's fine — the value is in giving programmers a framework for reasoning about when their instincts are justified and when they're not. If you've ever refactored code by moving a branch and felt uncertain whether the transform was semantics-preserving, this is the post that hands you the proof.
