A new Swift video series exploring functional programming and more.
#44 • Monday Jan 21, 2019 • Subscriber-only

The Many Faces of Flat-Map: Part 3

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.

This episode builds on concepts introduced previously:

#44 • Monday Jan 21, 2019 • Subscriber-only

The Many Faces of Flat-Map: Part 3

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.

This episode builds on concepts introduced previously:


Subscribe to Point‑Free

This episode is for subscribers only. To access it, and all past and future episodes, become a subscriber today!

See subscription optionsorLog in

Sign up for our weekly newsletter to be notified of new episodes, and unlock access to any subscriber-only episode of your choosing!

Sign up for free episode

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:

Subscribe to Point-Free

👋 Hey there! Does this episode sound interesting? Well, then you may want to subscribe so that you get access to this episodes and more!


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!

Chapters
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