So let’s talk the third and final part of “what’s the point?”. We’ve now spent a bunch of time getting comfortable with the idea of flatMap
, justifying why we should use it, and why we should build an intuition for it. Once we did that, we convinced ourselves that the signature of flatMap
and its friends is so important that we’re going to defend it from anyone that may disparage it: you shouldn’t change its signature, it’s there for a reason.
The reason we’ve done all this work is that now we can build off that foundation and ask very complex questions: questions that may have been seemingly intractable had we not taken this deep journey of discovery.
We’re going to look at composition of functions when it comes to flatMap
. We saw that map
had a wonderful property: the map
of the compositions is the same as the composition of the map
s. What that meant was that if you have a big chain of map
s, you can collapse all that into a single map
and call it once with the composition of all the units of work. Is there a version of this for flatMap
? There is!
Next, we know that flatMap
can flatten nested containers, like optionals of optionals and results of results, but what about nested containers of different types, like an array of results, or array of parallels, etc. Is there anything we can discover with those kinds of nested containers.
Finally, what is the precise relationship between map
, zip
, and flatMap
? Can some operations be derived from others, what does it say about types that can do so, and is there some kind of hierarchy between these things?
These are some pretty complicated questions that we want to ask and we can finally answer them!