Algebraic APIs

[briancavalier]

I've added map, flatMap, and ap to the when3 branch:

• promise.map(f) - apply f to promise's fulfillment value and return a new Promise for the verbatim result. This is different from promise.then(f), which recursively resolves the result of applying f.
• promise.flatMap(f) - f must return a promise. Apply f to promise's fulfillment value, return the resulting promise (technically: return a trusted promise equivalent to it, since f may return an untrusted promise)
• promise1.ap(promise2) - assume that promise1's fulfillment value is a function. When promise1 fulfills with a function, apply that function to promise2's fulfillment value, and return a promise for the result.

We really need to think carefully about how to document, since many JS devs may not be familiar with them. If we suspect these will cause utter confusion, we should consider postponing them.

They also need unit test coverage :)

[jorgemsrs]

Hello @briancavalier . Still need a hand in this? it seems the branch has been cut already.

[briancavalier]

Hey @jorgemsrs! It's kind of a long story, but yeah, I removed them before when 3.0 was released.

TC39 went round and round on the ES6 Promise API... first flatMap was in, then it was out, then in again, and eventually out, in favor of just sticking with then() as defined in Promises/A+. In a sense, then(f) acts like flatMap(f), but conditionally lifts the result of f to a promise if f returns a non-promise.

Allowing map would make it possible to create a "promise for a promise for X". While that's perfectly reasonable algebraically, TC39 felt it wouldn't have many use cases and would be confusing for many developers (ap/Applicative is likely in the same boat).

IOW, they felt that it would be less confusing for people to "just use then", and have it work like Promises/A+.

All of that said, I'm a big fan of algebraic APIs :) So, I'm certainly happy to discuss. I'd love to hear your thoughts on use cases, and whether people would find these to be useful.

[jorgemsrs]

imho tc39 are focused on writing the simplest working api possible in order to keep the learning curve smooth hence bringing everyone "into the loop". this means the tradeoffs will not keep everyone 1/1 happy. generating a consensus with so many opinionated people is a daunting task. it turns to be even harder given the sheer widespread usage of js.

on building algebraic api on top of promises i think this is where libs such as when will shine, augmenting the possibilities given by the language itself. having said this not everyone thinks on promises (and for what its worth, values/expressions in general) as algebraic operators so good examples covering real use cases could be supplied to teach by example.

*map, ap, cartesian product, etc are useful on their own. i'll try and formulate real use cases. I'll keep you posted.

ps: wouldn't it be awesome to have op overloading as part of the lang? this would make for such elegant implementations!

[briancavalier]

imho tc39 are focused on writing the simplest working api possible

Absolutely.

i'll try and formulate real use cases. I'll keep you posted.

That'd be great. Please let me know. This could be something we consider for 4.0.

One potential issue I know if is that bluebird already has promise.map, but it's not algebraic map :( It assumes that the promise contains an array, and runs array.map on it. So, it's not parametric, and fails (!) if the promise doesn't contain an array. That doesn't mean we shouldn't add our own algebraic map--just something to be aware of.