Why applicatives are monoidal27 Oct 2019 ⇐ Notes archive
(This is an entry in my technical diary. 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.”)
I still don’t quite have the foundation to grok the “lax” and “tensorial strength” bits (I will, some day). Yet, seeing applicatives as monoidal always felt out of reach.
They’re often introduced with the
apply duo (sketched out below for
(An aside, it finally clicked that the choice of “applicative” is, because, well, it supports function application inside of the functor’s context.)
And then, coincidentally, I recently asked:
is there any special terminology around types that support a
zipin the same way functors have a
mapand monads have a
To which, Matthew Johnson let me in on the secret.
zipis an alternate way to formulate applicative
That makes way more sense and sheds light on why Point-Free treated
zip as their big three instead of introducing
I can only sort of see that
apply implies monoidal-ness (pardon the formality) in that it reduces an
Optional<(A) -> B> and
Optional<A> into a single
Optional<B>. However, the fact that they contained different shapes always made me wonder.
zip relays the ability to combine more readily. “Hand me an
Optional<A> and an
Optional<B> and I’ll give you an
Yesterday, I finally got around to defining
apply in terms of
zip to see the equivalence.
Funnily enough, Brandon pointed me to exercise 25.2 which asks exactly this.
- Functors allow for a
- Applicatives, a
- Monads, a