I agree, and I actually think a better word for `bind` is `then`.

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.

I kind of agree with this... In many monads binding creates a time-dependent sequentiality!

But there are some that do not. For instance, the "reverse state monad" would not make sense with 'bind' named 'then' since... as the name implies, state flows backwards through time in it!

Every time I see one of the monad articles I think "this looks like promises, except it has a nicer syntax in Haskell".

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

Sure.

A little while ago there was an article (https://news.ycombinator.com/item?id=9907435) which suggested code like

    if (cond1)
      return val1;
    if (cond2)
      return val2;
    if (cond3)
      return val3;

    return defaultVal;

is simpler and better than

    if (cond1) {
      return val1;
    } else if (cond2) {
      return val2;
    } else if (cond3) {
      return val3;
    } else {
      return defaultVal;
    }

or something like that. In a certain sense this is objectively false as the second one uses fewer features than the first (a statement we can make formal using monads, but that's unrelated). I'd argue this is doubly true because whenever non-linear flow control begins to be used pervasively it is hard to know what code will be executed and under what conditions. With nesting at least these conditions are obvious.

In any case, we can solve this conundrum through the existence of an Option or Maybe type which encapsulates the imperative behavior of short-circuiting failure directly and limits it's scope.

If we have let's say:

    fa.then( f(ra) {
      return fb(ra);
    }).then( f(rb) {
      return fc(rb);
    })

rather than (if I understand the monadic way of doing things correctly)

    ra <- fa()
    rb <- fb(ra)
    rc <- fb(rb)

How is the scope of the short-circuiting limited? We will obtain a None result in case of error but we still do not know when the error occurred. Granted, we can add some guards but so can we with promises. Since the return statements are always at the end of each separate function the scope should not be a problem?

I am kind of new to this so please bear with me. Thanks.

Np!

The idea is that from "inside", as we are using do-notation, we merely think of working in an imperative language where failure might occur and short circuit things while from "outside" we see the type of this computation as Maybe and can examine whether or not it actually failed. The "inside"/"outside" dynamic is the scope delimitation.

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

Not intrinsically, IMO. The main value of monads is the shared interface, and its utility is contingent on tools that recognise that interface.

In that respect, it's as useful as providing e.g. a `map` method for promises, arrays, dictionaries, etc. Though in my experience JavaScript rarely seems to be written with this kind of generic interface in mind (e.g. there's no coherent interface mandated between classes in the standard library).