Programming in Scala”

Chapter notes 40
apply(u, unit(y)) == apply(unit(_(y)), u)
This law is essentially saying that unit is not allowed to carry an effect with regard to any
implementation of our applicative functor. If one argument to apply is a unit, then the other can
appear in either position. In other words, it should not matter when we evaluate a unit.
Composition
The composition law for apply is stated as:
apply(u, apply(v, w)) == apply(apply(apply(unit(f => g => f compose g), u), v), w)
This is saying that applying v to w and then applying u to that is the same as applying composition
to u, then v, and then applying the composite function to w. Intuitively it’s saying the same as:
u(v(w)) == (u compose v)(w)
We might state this law simply as: “function composition in an applicative functor works in the
obvious way.”
Applicative normal form
The applicative laws taken together can be seen as saying that we can rewrite any expression
involving unit or apply (and therefore by extension map2), into a normal form having one of the
following shapes:
pure(x)
// for some x
map(x)(f) // for some x and f
map2(x, y)(f) // for some x, y, and f
map3(x, y, z)(f) // for some x, y, z, and f
// etc.
Where f, x, y, and z do not involve the Applicative primitives at all. That is, every expression in an
applicative functor A can be seen as lifting some pure function f over a number of arguments in A.
Note that this reasoning is lost when the applicative happens to be a monad and the expressions
involve flatMap. The applicative laws amount to saying that the arguments to map, map2, map3, etc
can be reasoned about independently, and an expression like flatMap(x)(f) explicitly introduces a
dependency (so that the result of f depends on x). See the note above on “The cost of power”.