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

The Many Faces of Flat-Map: Part 4

Continuing our 3-part answer to the all-important question “what’s the point?”, we show that the definitions of map, zip and flatMap are precise and concisely describe their purpose. Knowing this we can strengthen our APIs by not smudging their definitions when convenient.

This episode builds on concepts introduced previously:

#45 • Monday Jan 28, 2019 • Subscriber-only

The Many Faces of Flat-Map: Part 4

Continuing our 3-part answer to the all-important question “what’s the point?”, we show that the definitions of map, zip and flatMap are precise and concisely describe their purpose. Knowing this we can strengthen our APIs by not smudging their definitions when convenient.

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

Avoiding smudging

Now we see map, zip and flatMap are an important trio of operations and each does one thing and does it well. We should now be able to convince ourselves that we shouldn’t be smudging their definitions just to suit our needs. We will likely come across functions with signatures that look a lot like flatMap and may even be tempted to call it flatMap, but doing so can destroy all of our intuitions around what flatMap is. Right now we have 6 types that we are very familiar with and all of the operations behave roughly the same, even for very different types.

And this lesson is an important one, but just 10 or 11 months ago we had a decisive moment in Swift history where the community got to learn from this and put it to real-world use. We actually had an entire episode dedicated to this back then, but now we are even in a better position to appreciate it, so let’s briefly recall the problem.

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

  • rename ELF.then to ELF.flatMap

    Apple • Monday Jan 21, 2019

    Apple’s Swift NIO project has a type EventLoopFuture that can be thought of as a super charged version of the Parallel type we’ve used many times on this series. It comes with a method that has the same signature as flatMap, but originally it was named then. This pull-request renames the method to flatMap, which brings it inline with the naming for Optional, Array and Result in the standard libary.

  • 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
Avoiding smudging
00:05
Flat-map vs. compact-map
01:25
Result's throwing maps and flat-maps
04:22
Types with no flat-map
09:00
Renaming flat-map
13:52
Implicit flattening
19:23
Till next time…
22:05