What are the implications of the recursive joining of Promises in terms of Monads?

by

The first issue can easily be bypassed by always providing a function with the right type a -> Promise a.

Or by not using then as the bind operation of the monad, but some type-correct ones. Creed is a functionally minded promise library that provides map and chain methods which implements the Fantasy-land spec for algebraic types.

The second issue can be bypassed as well with the same approach, by not using resolve but fulfill instead, and the static of method as the unit function.

But what would this structure mean in the context of promises/asynchronous computations?

It’s a promise for a promise for a value. Not every constructible type needs to be “meaningful” or “useful” 🙂

However, a good example of a similar type is provided by the Fetch API: it returns a promise that resolves to a Response object, which again “contains” a promise that resolves to the body of the response.

So a Promise (Promise a) might have only one success result value, which could as well be accessed through a Promise a, however the two levels of promises

  • might fulfill at different times, adding a “middle step”
  • might reject with different causes – e.g. the outer one representing a network problem while the inner one represents a parsing problem

Notice that the Promise type should have a second type variable for the rejection reason, similar to an Either. A two-level Promise err1 (Promise err2 a) is quite different from a Promise err a.

I know that Javascript’s promises are technically neither functors nor monads in the sense of Haskell

You haven’t mentioned the biggest issue yet, however: they’re mutable. The transition from pending to settled state is a side effect that destroys referential transparency if we consider execution order, and of course our usual use cases for promises involve lots of IO that isn’t modelled by the promise type at all.

Promise.delay(50).then(() => Promise.delay(50))
// does something different than
const a = Promise.delay(50); a.then(() => a)

Applying the monad laws is fun and occasionally useful, but we need lots of pragmatism indeed.

More Related Contents:

  1. What is the explicit promise construction antipattern and how do I avoid it?
  2. How to return many Promises and wait for them all before doing other stuff
  3. How to dodge jQuery promises completely when chaining two async jQuery functions?
  4. Cancel a vanilla ECMAScript 6 Promise chain
  5. When is the body of a Promise executed?
  6. fetch: Reject promise with JSON error object
  7. ES6 Promise.all() error handle – Is .settle() needed? [duplicate]
  8. How do I tell if an object is a Promise?
  9. How to check if an object is a Promise?
  10. How to use promise in forEach loop of array to populate an object
  11. Should a Promise.reject message be wrapped in Error?
  12. What do double brackets mean in javascript and how to access them
  13. using a fetch inside another fetch in javascript
  14. Why does the Promise constructor require a function that calls ‘resolve’ when complete, but ‘then’ does not – it returns a value instead?
  15. What is the difference between “event loop queue” and “job queue”?
  16. What are asynchronous functions in JavaScript? What is “async” and “await” in JavaScript?
  17. When would someone need to create a deferred?
  18. What is the intention behind clause 2.2.4 of Promise/A+ spec?
  19. Promises, pass additional parameters to then chain
  20. How to extract data out of a Promise
  21. Promise and Promise.all(array) executed before array fulfilled [duplicate]
  22. Node.js: When to use Promises vs Callbacks
  23. How can I export promise result?
  24. Are JavaScript forever-pending promises bad?
  25. ES6 Promise replacement of async.eachLimit / async.mapLimit
  26. Why does JavaScript Promise then handler run after other code?
  27. When is the body of a Promise constructor callback executed?
  28. Promise.all is returning an array of undefined and resolves before being done
  29. Weird behavior with Promise throwing “Unhandled promise rejection” error
  30. Promise.resolve().then vs setImmediate vs nextTick

Leave a Comment