Hacker News Reader

Comment by explaininjs | Hacker News Reader

We might consider promises “applied monads” or “engineered monads”. Monodic in inspiration and they solve the same core problem, but they aren’t straightjacketed into the ivory tower “laws” in absolutely every edge case (they do satisfy them in the vast majority of cases). Which is good, because it means we never need to write things like “await await await await await foo()”

View on HN

> Which is good, because it means we never need to write things like “await await await await await foo()

But what your describing is the actual value proposition of monad though! It's literally the construct you use to avoid excessive unwraps.

Look at the type signature of bind:

  m a -> (a -> m b) -> m b

It returns m b. Not m (m b). Not m (m (m b)).

> but they aren’t straightjacketed into the ivory tower “laws” in absolutely every edge case

In other words, you can't abstract over them. If you have libraries that manipulate monads, they will be incompatible or buggy, because they will assume (by design) behaviour that a non-monad will not live up to.

I should not need to explain to you that the problem is when b itself is internally an (m b’). Or when it is a sum of many types, of varying m-nests.

I can assure you that JS libraries work with Promises just fine.

This is all besides the root topic though, which is that CPS and Monads are isomorphic. Which is true. Promises are a different thing.

Reply on news.ycombinator.com