The Many Faces of Flat‑Map: Part 3

Episode #44 • Jan 21, 2019 • Subscriber-Only

We are now ready to answer the all-important question: what’s the point? We will describe 3 important ideas that are now more accessible due to our deep study of map, zip and flatMap. We will start by showing that this trio of operations forms a kind of functional, domain-specific language for data transformations.

The Many Faces of Flat‑Map: Part 3
What’s the point?
00:05
Imperative nil handling
02:31
Nil handling pipelines
08:19
Imperative error handling
15:12
Error handling pipelines
19:35
Validation pipelines
24:08
Lazy pipelines
26:55
Asynchronous pipelines
29:58
Till next time
35:33

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.

What’s the point?

It’s time to ask “what’s the point?” and “what’s the point is three-fold. We are going to discuss three important aspects in having a deep understanding of flatMap:

  1. We are going to show that map, zip and flatMap form a kind of functional, domain-specific language for modeling pipelines of data. And seeing a usage of one of these operators we will already have a strong intuition for what that line of code could possibly be doing, without even knowing too much about the types involved.

  2. Once we see that we will have convinced ourselves that these operations have a very well-defined signature, and we shouldn’t be smudging it in order to suite our needs. Sometimes we’ll have a function signature that looks kinda like flatMap but it isn’t quite and we’ll want to call it flatMap for ease. We want to make the case that everything we have learned shows us that is the wrong decision, and our APIs will be better off if we do not do that.

  3. And then finally, we begin to ask ourselves very complex questions about how all of these operators interact with each other. These are problems that we feel would have been intractable if we didn’t already have a solid foundation of understand the purpose of map , zip and flatMap, and we would have had a very difficult time coming up with any concise, clear answers.

The meanings behind the signatures of map, zip and flatMap are very concise, and describe very well what their purpose is. This intuition is so strong that we can be presented with a whole new type that we are not familiar with and be told it has a map operation and instantly know that means we can unwrap the type, apply a transformation and wrap it back up. Or be told that it has a zip operation and so that we can take a bunch of values, independently run their computations, and obtain a new, single value from the type. Or be told that it has a flatMap operation, and now you know you can can sequence these values together so that one follows another.

So, let’s look at what power this gives us by looking at some interesting uses of these operators on some concrete types:

This episode is for subscribers only.

Subscribe to Point-Free

Access this episode, plus all past and future episodes when you become a subscriber.

See plans and pricing

Already a subscriber? Log in

References

SE-0235: Add Result to the Standard Library

Wednesday Nov 7, 2018

The Swift evolution review of the proposal to add a Result type to the standard library. It discussed many functional facets of the Result type, including which operators to include (including map and flatMap), and how they should be defined.

Railway Oriented Programming — error handling in functional languages

Scott Wlaschin • Wednesday Jun 4, 2014

This talk explains a nice metaphor to understand how flatMap unlocks stateless error handling.

When you build real world applications, you are not always on the “happy path”. You must deal with validation, logging, network and service errors, and other annoyances. How do you manage all this within a functional paradigm, when you can’t use exceptions, or do early returns, and when you have no stateful data?

This talk will demonstrate a common approach to this challenge, using a fun and easy-to-understand “railway oriented programming” analogy. You’ll come away with insight into a powerful technique that handles errors in an elegant way using a simple, self-documenting design.

A Tale of Two Flat‑Maps

Brandon Williams & Stephen Celis • Tuesday Mar 27, 2018

Up until Swift 4.1 there was an additional flatMap on sequences that we did not consider in this episode, but that’s because it doesn’t act quite like the normal flatMap. Swift ended up deprecating the overload, and we discuss why this happened in a previous episode:

Swift 4.1 deprecated and renamed a particular overload of flatMap. What made this flatMap different from the others? We’ll explore this and how understanding that difference helps us explore generalizations of the operation to other structures and derive new, useful code!