Monads in JavaScript

  const f1 = function(s) {
    let data;
    try {
      data = JSON.parse(s);
    } catch (err) {}

    if (data != null &&
        data.a != null &&
        data.a.b != null &&
        typeof data.a.b.c === 'string') {
      let x = parseFloat(data.a.b.c);
      if (x === x) {
        return x;
      }
    }
    return null;
  };

  const f2 =
  R.pipe(S.parseJson,
         R.chain(S.gets(['a', 'b', 'c'])),
         R.filter(R.is(String)),
         R.chain(S.parseFloat),
         S.fromMaybe(null));

  data.a.b.c

We can apply functional programming concepts to JavaScript code to obviate the need for null/undefined checks. The fact that we can't have all the benefits of FP in JS shouldn't dissuade us from taking advantage of the ideas which are applicable.

Very few languages in use are fairly described as "non-functional"; pretty much any structured programming languages that supports function pointers supports the functional paradigm. A language doesn't have to be pure to support functional programming.

However, we must chain these into useful programs somehow. Monad is the type name chosen in Haskell for the construct that does this. It's kind of simple if you work it backwards from the syntax. You want to be able to say

    do
      a <- readInt
      b <- readInt
      add a b
      print

Hence, the Monad. It wraps a real world concern around a type (it has a type constructor). You must be able to make one from a concrete value that is unburdened with exceptional state (it has the unit function). You must be able to call pure functions on these monadic values without the side state seeping into the function (it has the bind function).

Edit: the reason you don't see Monads in other languages is because they're not essential to them. You can do stuff in C without Monads. To Haskell, Monads are like the Higgs boson. It's how you bind stuff together.

A functor is a type parameterized by another type[1], say 'a', with a function 'fmap' taking a function 'a -> b', yielding the original object except that its type is now parameterized by 'b'[2]. A monad's 'join' operation takes 'f (f a)' onto 'f a'.

On top of this, there are certain laws which must be obeyed. The functor laws amount to saying that 'fmap' can't change anything about the object (including structure) which doesn't depend on the parameter 'a', but must change everything which does depend on 'a'. The monad laws amount to saying that 'join' has a certain associative structure[3], and also that there is a left- and right-identity 'return: a -> f a'.

[1] a la Java generics, for those not into FP

[2] i.e., fmap has type 'forall a b. (a -> b) -> (f a -> f b)'

[3] Explaining exactly what this associative structure is in these terms is tricky, since 'join' as described is unary. Here's where you have to introduce the function 'bind', '(\f -> join . fmap f)': 'bind g . bind f' === 'bind (bind g . f)'. But it's really not essential; the most intuitive consequence is that Haskell's 'do' notation works like you want it to.

I've struggled with blog posts about monads countless times. Maybe I just find it easier to listen to some explanations rather than read them.

"A monad" isn't a thing, but we can ask what it takes for something to "have monad-nature" or "be a monad". For this to occur our something must be three things, a triple

    (T, mu, eta)

T must be what's known as a Functor. For PLs really, though, it's even more specific. It's an "endofunctor on the type category of your language". What this means is simple

* For any (static) type `a` in your language, `T a` is also a static type.

* For any function `f` from type `a` to type `b`, `T f` is a function from type `T a` to `T b`.

If your language doesn't have static types then you can approximate this by pretending that it does. Also note that `T f` is not usually the syntax used, but it'll do for now.

Now to make a monad we take any choice of Functor `T` and give it two operations. `eta` takes values in type `a` to values in type `T a` while `mu` takes values in type `T (T a)` to values in type `T a`. In other words they give you a "layer manipulation toolkit".

They must follow laws as well, but these laws are all "common sense laws" which allow you to think of values in the following types: `a`, `T a`, `T (T a)`, `T (T (T a))`, `T (T (T (T a)))`, ... as all being the same as values with just one layer: `T a`. This is the "flatten" idea.

And there you have it! Anything at all which can be regarded as equivalent to one of these triples following this design and laws is a monad!

---

So the real question is why should someone care? The answer is simple.

Lots of things have monad-nature in a typed language. By recognizing their common nature we can (a) see them in a new light full of perhaps previously unknown similarities, (b) share terminology lightening the burden of how to use them, (c) write generic operations which work over any monad and expect them to work with each specific one in a similar way, (d) introduce new syntactic sugar which is built entirely from (mu, eta) and expect it to work similarly for every thing with monadic-nature, (e) begin to form theories and impressions of "what it means to be a monad".

The reasons (a-d) show up all the time once you recognize this pattern since monads are really common.

Reason (e) is what everyone wants to hear about but it's hard to talk about without being super arm-wavey. But I'll try.

In order to provide the operation `mu :: T (T a) -> T a` the type `T a` must be able to "internalize itself" without losing too much information. In order to follow the laws, one bit of important information is an idea of sequence or nesting—but one unique to each particular monadic triple.

In this way monads are a very, very, very general way of talking about sequencing or nesting.

What makes thins interesting is that you can see imperative languages as being about sequencing or nesting as well. If you have a listing of statements { X ; Y ; Z } then you can see { Y ; Z } as being nested in the execution context that X created and { Z } being nested in the execution context that { X ; Y } created.

This would maybe make you think that imperative languages have monad nature and indeed they do. This leads to an interesting study of questions like "For some given imperative language, what is a pure-functional representation of the monad representing it?" which sometimes has interesting answers.

What's even more interesting is that one example of reason (d) above is to introduce a syntax sugar which makes any monad look a bit like an imperative language. This leads to an interesting study of questions like "What does the imperative language for some monad X feel like?"

So if you really like imperative languages and recognize that there's a larger design space here that most have any familiarity with then monads are a good thing to keep an eye out for.

For anyone unfamiliar, the `then` of Promises corresponds to the monadic `bind` or `flatMap` (if the given function returns a Promise) or the functorial `map` (if the given function returns a plain value).

A monad then is just the interface shared between Promises (`then` and `resolve`, collections (`flatMap` and `wrap`), etc.

The hard part for me was visualising the pattern for more complicated types like parsers (functions from strings to results) and continuations.

Is there any reason to use monads in (let's say) Javascript rather than promises? Are there any performance gains?

Consequently, whenever someone feels they understand Monads they are compelled to write a tutorial to demonstrate their understanding and consequent elevation to "true programmer" status. There is a large audience for these tutorials as all the "non-true" programmers struggle to reach this stage.

I certainly only wanted to understand Monads because they sounded cool, not really because I wanted to become a better programmer. Although I certainly found this to be quite a positive side-effect in my struggles to become a "true" programmer.

They don't teach you number theory before arithmetic in primary school. Similarly, you don't need to understand monads before you use IO.

Example:

  Valid("userId").flatMap(userId =>
    Invalid("address").map(address => User(id = userId, address = address))

  def flatMap[B](f: A => Validation[B]): Validation[B] = this match {
    case Valid(value) => f(value)
    case Invalid(value) => Invalid(value)
  }

  def map[B](f: A => B): Validation[B] = this match {
    case Valid(value) => Valid(f(value))
    case Invalid(value) => Invalid(value)
  end

  for {
    userId <- Valid("userId")
    address <- Invalid("address")
  } yield {
    User(id = userId, address = address)
  }

As a simple example, if you'll buy that by your reasoning OCaml would find monads to be a "useless, redundant abstraction which will only clutter the code", then I'd ask why both Async and Lwt are built to be monadic? Or, if you still feel that's a mistake, how you'd design them elsewise?

E.g. I can use Future for managing async-ness. I can use a system a bit like http://typelevel.org/blog/2013/10/18/treelog.html for weaving statistics collection through my computation. I use Free to express database operations that need to happen in a transaction. I can use Either to handle operations that might fail.

I can write a method that builds a report from a bunch of rows that works with any of these four contexts, because all of them form monads.

http://book.realworldhaskell.org/read/io.html#io.lazy

Haskell's do notation is syntactic sugar over monads which effectively allows you to write 'imperative-looking' code while still carrying a local state forward without mutation. The Wikibook[1] does a pretty good example of explaining what this looks like (though I'm guessing you already know this).

Now, obviously it is true that one of do notation's advantages is the same as any other monad usage: it allows us to explicitly sequence events in a lazy language that otherwise offers no (obviously intuitive) guarantees on evaluation order. In that sense it's nothing more than sugaring over the otherwise necessary usage of a lot of ugly >> and >>= operators everywhere in increasingly annoying indentation.

But the other thing it offers is a syntactic sugaring over carrying state forward into successive computations (like the State monad[2]), which still carries at least some useful sweetness in a language that is otherwise functionally pure, which is why F# generalized the concept even further to computation expressions[3].

Looked at another way, do notation, or something like it, can be used to sugar over something that rather more looks like the Clojure ->/->> operators, where the initial value is essentially a local namespace. Much like the threading macros, the result even appears to be doing a kind of mutation, even though it's actually doing nothing of the sort.

This kind of thing turns out to be useful for games, for instance, as the linked State monad example above does. In games we often have a main update loop, where we have to do several successive operations on our game that might change the state. We can do this a number of ways, but one way is with something like do notation, where for instance (in some hypothetical language) we might do this:

  do with gameState
    oldGame <- gameState
    gameState <- checkInput
    gameState <- tick
    if gameState != oldGame
      draw

You can write whole imperative, mutation-riddled languages in purely functional ones this way. There's an implementation of BASIC that runs in the Haskell do notation.[4]

[1] https://en.wikibooks.org/wiki/Haskell/do_notation [2] https://wiki.haskell.org/State_Monad [3] http://tomasp.net/blog/2013/computation-zoo-padl/ [4] http://augustss.blogspot.fi/2009/02/is-haskell-fast-lets-do-...