Tag Archives: Monads

Swift 2.0: Map and FlatMap Demystified

Swift 2.0: Map and FlatMap Demystified
// Umberto Raimondi’s Blog

This is a Swift 2.0 article, get this and other playgrounds from GitHub.

Swift is a language still slightly in flux, with new functionalities and alterations of behavior being introduced in every release. Much has already been written about the functional aspects of Swift and how to approach problems following a more “pure” functional approach.

Considering that the language is still in its infancy, often, trying to understand some specific topics you’ll end up reading a lot of articles referring to old releases of the language, or worst, descriptions that mix up different releases. Sometimes, searching for articles on flatMap, you could even fortuitously find more than one really good articles explaining Monads in the context of Swift.

Add to the lack of comprehensive and recent material the fact that many of these concepts, even with examples or daring metaphors, are not obvious, especially for someone used to the imperative way of thinking.

With this short article I’ll try to give a clear and throughout explanation of how map and especially flatMap work for different types in Swift 2.0, with references to the current library headers.

From Imperative to Pure-Functional and Back Again: Monads vs. Scoped Continuations

via Parallel Universe.

Last month I gave a talk at the Curry On conference, a new conference co-located with the academic, programming language conference,ECOOP. Curry On is intended to bridge the gap between academia and the industry. My academic interests do not include programming languages, which I view as the sub-discipline of computer science that has consistently over-promised and under-delivered more than any other (with the possible exception of AI). I am more interested in algorithms than abstractions, and programming language research is mostly concerned with the latter. Nevertheless, as a developer, I must use the abstractions provided by the programming languages I choose to use, and it was with some alarm that I had noted a flow of certain abstractions from academic languages to the mainstream that, in some cases, make a bad fit and mostly cause pain. As an example, I’d like you to ponder the fact that many, many more people now use monads in Java than in Haskell.

In my talk I made the case that the core abstraction of imperative programming is the blocking thread. Once you take it away, you lose most other imperative abstractions like control flow and exception handling (requiring them to be re-implemented in libraries), and most of the advantages imperative languages bring like post-mortem debugging, profiling, and automatic backpressure. It also makes code harder to write and read. Asynchronous programming is, I claim, anathema to imperative languages, whether or not you use monads to ease its pain. The mismatch between async and imperative is fundamental. All the while, we can reach for an abstraction just as powerful as monads – if not more so – which is a natural fit for imperative languages, meshing perfectly with their structure and abilities.

Swift Functors, Applicatives, and Monads in Pictures

via Swift Functors, Applicatives, and Monads in Pictures | mokacoding.

This is a translation of Functors, Applicatives, And Monads In Pictures from Haskell into Swift.

I don’t want to take any merit for writing this, I only went through the fun exercise of translating the code snippets in Swift.

If you enjoy this post be sure to say thanks to the author of the original version: Aditya Bhargava,@_egonschiele on Twitter.

Despite all the hype about it, Swift is not a functional language. This means that we need to write a bit of extra code to achieve the same results that language like Haskell have with built-in operators.

You can find a Playground with all the code from the article on GitHub.

Finally, don’t worry if you find the content hard to grasp. I had to read the original version a number of times to wrap my head around it, plus a lot of mess around with the Swift code.

Monads in JavaScript

via Monads in JavaScript — Curiosity driven.

Monad is a design pattern used to describe computations as a series of steps. They are extensively used in pure functional programming languages to manage side effects but can also be used in multiparadigm languages to control complexity.

Monads wrap types giving them additional behavior like the automatic propagation of empty value (Maybe monad) or simplifying asynchronous code (Continuation monad).

To be considered a monad the structure has to provide three components:

  1. type constructor — a feature that creates a monadic type for the underlying type. For example it defines the typeMaybe<number> for the underlying type number.
  2. the unit function that wraps a value of underlying type into a monad. For the Maybe monad it wraps value 2 of the typenumber into the value Maybe(2) of the type Maybe<number>.
  3. the bind function that chains the operations on a monadic values.

Video: Networking with Monads

* Discuss what makes a monad (bind / return)
* Show how Optional and Result are monads
* Discuss “Deferred” (Swift implementation of http://ocaml.janestreet.com/ocaml-cor…)
* Briefly mention monad transformers
* Demo simple chat client/server that uses all of these concepts (e.g., how “connect and handshake” is relatively simple with monadic error handling)

Video: Monads and Gonads

The wonders of monads are finally revealed without resorting to Category Theory or Haskell. It turns out that monads are trivially expressed in JavaScript, and are one of the key enablers of Ajax. Monads are amazing. They are simple things, almost trivially implemented, with enormous power to manage complexity. But understanding them is surprisingly difficult, and most people, once they have that ah-ha moment, seem to lose the ability to explain them to others.

Response to “Monads” (and Functional Programming)

via Response to “Monads” (and Functional Programming) – owensd.io.

Rui Peres asked me for my opinion about a piece he wrote about Monads, partially the context of Swift. Sure!

I’m by no means an expert in functional programming, so be sure to question all things I say. =) Chris Eidhof knows this stuff much, MUCH better than I do and could probably offer a much different perspective.

So, my thoughts… well. It’s more complicated than that. =) It’s more complicated because it actually feeds into something I’ve been feeling for many years and only recently really been trying to understand and figure out if there is something tangible I can do to make it better, if for no one else, at least for myself.

So, general critique of the article: I think it was a fair overview of monads and somewhat of an introduction to functional programming in general. I would have maybe added some mention about monads and their use for capturing side-effects in programs, but that’s about it. Oh, and make sure the code samples work and state the version of Xcode the Swift samples work on as that’s a moving target.

As for functional programming in general: I think there is a tendency to treat it as a magic bullet for solving many of the problems in computer science. Now, this is not to knock on functional programming in the slightest; I believe that it’s a paradigm that can teach us many good things. But like everything, it must be used in proper moderation and with care in order to be truly effective.

When I think of functional programming, I see it as trying to apply some core principles to your code base. I would call these out as:

Functional evaluation – everything is a function and should be composable.
Clean state – side effects should be scoped to their context.

And that’s really it; everything else stems from those two things. Composable functions like map are just a satisfaction of goal #1. Monads are a way to make goal #2 happen. At the end of the day, these are all abstractions.

Here’s the thing to remember though: there’s no such thing as zero-cost abstractions (slides, video). I’ll touch on this a bit more later.