Why applicatives are monoidal

27 Oct 2019 ⇐ 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.”)

---

“Applicative functors are […] lax monoidal functors with tensorial strength.”

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 pure and apply duo (sketched out below for Optional).

(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 zip in the same way functors have a map and monads have a flatMap?

To which, Matthew Johnson let me in on the secret.

zip is an alternate way to formulate applicative

!!!.

That makes way more sense and sheds light on why Point-Free treated map, flatMap, and zip as their big three instead of introducing pure and apply.

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 Optional<(A, B)>.”

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.

In short,

• Functors allow for a map.
• Applicatives, a zip.
• Monads, a flatMap.