Empty reducers and the monoidal unit
08 Sep 2020 ⇐ Notes archive(This is an entry in my technical notebook. There will likely be typos, mistakes, or wider logical leaps — the intent here is to “let others look over my shoulder while I figure things out.”)
Most writing about monoids starts by listing out the axioms (or in programming, the protocol or type class requirements) before diving into examples. And as Jeremy Kun notes, “[this is not only confusing, but boring (!)] to an untrained student. They don’t have the prerequisite intuition for why definitions are needed, and they’re left mindlessly following along at best.”
The Point-Free duo does a wonderful job at avoiding this — episodes start with and cover examples until a common shape is noticed and then chip away specializations until a more general form, and in turn, the axioms shake out. Rephrased, making an axiom earn its keep by pointing out problems that occur in its absence.
In episode #116, Brandon and Stephen did just that with the Reducer type’s monoidal unit. Instead of conforming Reducer to Monoid, they instead guided us into a situation — disabling logic on redacted views — where an inert reducer is needed to avoid state mutations and side effects. Or under their library’s name, Reducer.empty.
They subtly dropped the need for this axiom roughly 16 minutes in and it felt worth the extra show note here.
For a longer treatment on the topic, here’s a timestamped link from one of Brandon’s older talks: “Composable Reducers and Effects Systems.”