Hacker News Reader

Comment by zoul | Hacker News Reader

IMHO callback hell is only called hell because of the syntax. So the solution admired here is mostly the do notation, not monads themselves. (But it’s a great feature that the do notation can be used for a general class of problems represented by monads, not a particular one as await, for example.)

View on HN

If do-notation is the solution, does that mean that adding syntax sugar for nested functions / promises in JS would solve the problem of callback hell as well? I somehow doubt that.

Yes — but only if, as in Haskell, that syntactic sugar was generalisable. The whole point of monads is that they are a powerful generalisation that can be used to solve many apparently very different problems. Compared with the syntactic sugar that other languages introduce to solve specific problems (list comprehension/LINQ, `await`, …). You suddenly get a grammar explosion because you keep expressing the same core concept differently.

> Yes — but only if, as in Haskell, that syntactic sugar was generalisable.

Only if you just need one type of monad. If you need interleave multiple monads, haskell syntax is worse because it makes no visible distinction between them.

There is no sensible interleaving of multiple monads, and any sensible language would prevent you from any kind of implicit interleaving.

In the article there are few monads mentioned: async, nested iteration, maybe, state passing. I can easily imagine sensible mixture of those, and languages with "ad hoc" solutions allow you to mix them.

The distinction is visible in the type.

... you mean like async / await?

If async await worked for the continuation monad, the typical list monad, and the maybe monad, then yes, async/await would be a good, if somewhat strangely named, construct

Reply on news.ycombinator.com