First off, I'm not sure it's even worth it to understand this stuff... Second, someone should be along to slam it soon enough and insist I've missed some gibberishy business that you'll never understand.

With those caveats in mind, here's a more intensive scala-based monad tutorial I made:

https://github.com/zaboople/techknow/blob/master/scala/monad...

But really, don't burn up too much of your short life trying to come to terms with this stuff. There's a reason most languages don't get around to supporting Monads...

It' really worth understanding. I studies Haskell and Scala to write better Python, Typescript, and Java, and it did help.

The whole thing about JS's Promises becomes way clearer when you see that they are a monad, except for one discrepancy (they auto-flatten themselves). It leads to much shorter and clearer code when doing pedestrian frontend stuff.

What parent describes is pretty simple: That's just how the compiler transforms some code.

Do-notation in Haskell, or for-comprehensions in Scala are just syntax sugar for nested calls to `flatMap`, `filter`, and `map`.

I think this here shows it nicely:

https://www.baeldung.com/scala/for-comprehension#for-compreh...

In Scala you can add the needed methods to any type and than they will "magically" work in for-comprehensions. In Haskell you need to implement a Monad instance which than does the same trick.

The concrete implementations of these methods need to obey to some algebraic laws for the data structure which defines them to be called a monad. But that's pretty much it.

In my opinion all that Haskell in most "monad tutorials" just blurs an in principle very simple concept.

The in practice relevant part is that a monad can be seen as an interface for a wrapper type with a constructor that wraps some value (whether a flat value, some collection, or even functions, makes no difference), does not expose an accessor to this wrapped value, and has a `flatMap` method defined. It also inherits a `map` method, coming from an interface called "Functor". The thing is also an instance of an "Applicative", which is an interface coming with a `combine` method which takes another object of the same type as itself and returns a combination of again the same type (classical example: string concatenation can be a `combine` implementation if we'd say that `String` implements the `Applicative` interface).

You might like https://philipnilsson.github.io/Badness10k/escaping-hell-wit... which is a longer version of the same kind of argument.

As original commenter I'll vouch for this one! It does give a much better & more detailed explanation of what I'm hinting at without math gibberish and whatnot.

To get a minimal idea, you can think about a monad as of a parametrized class: M<T>. Its functioning follows "monad laws" that allow you to do certain things with it, and with the value(s) of T wrapped my it. In particular, you can always "map" the values:

  M<T1>::map(f: (T1 -> T2)): M<T2>
  List<int>([1, 2, 3]).map(x => toString(x)) == List<string>(["1", "2", "3"])

You can always flatten the nested structure:

  M<M<T>>::flatten(): M<T>  // [["a", "b"], ["c", "d"]] -> ["a", "b", "c", "d"]

This is usually expressed in a different form, more fundamental:

  M<T1>::flatMap(f: (T1 => M<T2>)): M<T2>
  List(["a b", "c d"]).flatMap(x => x.split()) == List(["a", "b", "c", "d"])

You can notice how that map() thing does looping over a sequence for you.

But Optional<T> is also a monad:

  let x: Optional<int> = Some(1);
  let y: Optional<int> = Nothing;
  x.map(n => n + 1).map(n => n * 2) == Some(4);
  y.map(n => n + 1).map(n => n * 2) == Nothing;

As you see, the same map() (and flatMap()) does the condition checking for you. and can be chained safely.

You can also notice how chaining of map-like operations does operation sequencing:

  fetch(url).then(content => content.json()).then(data => process(data))

Your language, like JS/TS, can add some syntax sugar over it, and allow you to write it as a sequence of statements:

  async () => {
    const response = await fetch(url);
    const data = await response.json();
    process(data);
  } 

Promises are not exactly monads though, a Promise<Promise<T>> immediately transforms into Promise<T>. But other monadic properties are still there.

> immediately transforms into

Minor quibble, "can only be resolved as". The runtime absolutely holds Promise<Promise<T>>'s.

Splitting hairs even further: the .then() returns a resolved value of the inner Promise, not the inner Promise itself, when the outer Promise resolves, so not "immediately" indeed. That's where the flattening occurs, AFAICT.

I wrote a post about a highly related topic here. It may be helpful to you in understanding the parent comment: https://chadnauseam.com/coding/random/how-side-effects-work-...