6 ms·
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?
by m1el 9y ago
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.
- klmr 9y agoYes — 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.
- scotty79 9y ago> 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.
- tathougies 9y agoThere is no sensible interleaving of multiple monads, and any sensible language would prevent you from any kind of implicit interleaving.
- scotty79 9y agoIn 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.
- tome 9y agoThe distinction is visible in the type.
- mej10 9y ago... you mean like async / await?
- tathougies 9y agoIf 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