Equational Reasoning: Two Functions, One Shape
Why a wrapper function that just forwards its argument is often unnecessary, and the technique for spotting when you can delete it.
The last few posts were all about reshaping a function's arguments with small adapter utilities. This one is about noticing when you don't need to touch the arguments at all, because you've probably written this pattern without ever naming it:
function onOrder(order) {
return processOrder(order);
}onOrder takes one input and does exactly one thing with it: hand it straight to processOrder. It adds nothing of its own.
Same Shape, Interchangeable
onOrder and processOrder share the exact same shape: both take one input, both return one output. Since they're interchangeable, you don't need the wrapper at all:
const onOrder = processOrder;Or more directly, skip the wrapper's name entirely and pass processOrder wherever onOrder would have gone:
orders.forEach(processOrder); // instead of orders.forEach(onOrder)Nothing about the behavior changed. The unnecessary middleman just disappeared.
The Names for This
Defining a function this way, without ever writing out its input explicitly, has a name: point-free style. The input, in math terms, is called a "point," so a definition that never names it is "point-free."
Two functions with the same shape are interchangeable, no matter how different their names or their bodies look.
The reasoning that gets you there also has a name: equational reasoning. It just means noticing that two functions have the same shape, and treating them as swappable because of it, the same move the last post built the vocabulary for.
Don't Force It, and Don't Overdo It
The first time you see point-free style, one of two unhelpful reactions is common. One is dismissing it outright because it looks unfamiliar. The other is the opposite: getting excited and rewriting everything in your codebase this way, whether it actually helps or not.
Both miss the point. A wrapper is worth deleting when the shapes genuinely match and removing it makes the code clearer, not just shorter. Adopting any new technique has a real learning cost, and point-free style is one of the easiest places to push past what actually helps and start hurting your own readability instead.
The next post works through a case where point-free style does more than trim a wrapper, it makes a relationship between two functions visible that would otherwise stay hidden.
Keep reading