Tab Atkins Jr. (2013-05-25T20:29:56.000Z)
On Sat, May 25, 2013 at 10:30 AM, Brendan Eich <brendan at mozilla.com> wrote:
> Sam Tobin-Hochstadt wrote:
>> In the meeting, there were (a) people advocating for styles of
>> programming along the lines that you (Tab) have put forward, like me,
>> (b) people advocating for Q-style programming, like Mark, Yehuda, and
>> Tom, and (c) genuine concern about the complexity budget of the
>> promise API, expressed most by Luke Hoban, but felt by all of us. Were
>> it not for this last concern, I think AP2 would have seemed more
>> attractive.  But since the set of methods available on Promises
>> themselves is the most visible part of the API, and AP2 doubles its
>> size, that told heavily against AP2.
>
> AP2 from Mark's slides:
>
> AP2 (Based on Tab’s latest)
> • Q.fulfill // lifting
> • Q() // autolifting, resolve
> • p.then // deep flattening
> • p.flatMap // “chain”

Apologies for being a broken record, but just to make sure the detail
isn't lost in the noise...

AP2 is *almost* right.  If .then() only flattens on the read side,
it's perfect.  The difference is undetectable to code that sticks
strictly with .then(), but it allows for easier composition with
.chain()-based code.

For example, a .then() callback can just return a promise from some
other function.  This other function *could* be returning a nested
promise (it might be a database which can hold promises, for example),
and so a .chain() off of it can usefully just unwrap the DB promise
and deal with the inner promise.  If .then() flattens on the return
side too, this possibility is lost - the unwrapping behavior infects
the chained future regardless of how you interact with it.

I'm ambivalent about whether .flatMap/chain() should be properly
monadic (rejecting the chained promise with a TypeError if you return
a non-promise from the callback) or have the same loose behavior as
.then() where it allows you to return a non-promise and figures out
what you mean.  I lean toward the former because .then() exists
already, but wouldn't die if the latter were chosen.

~TJ
github at esdiscuss.org (2013-07-12T02:27:21.474Z)
On Sat, May 25, 2013 at 10:30 AM, Brendan Eich <brendan at mozilla.com> wrote:
> Sam Tobin-Hochstadt wrote:
>> In the meeting, there were (a) people advocating for styles of
>> programming along the lines that you (Tab) have put forward, like me,
>> (b) people advocating for Q-style programming, like Mark, Yehuda, and
>> Tom, and (c) genuine concern about the complexity budget of the
>> promise API, expressed most by Luke Hoban, but felt by all of us. Were
>> it not for this last concern, I think AP2 would have seemed more
>> attractive.  But since the set of methods available on Promises
>> themselves is the most visible part of the API, and AP2 doubles its
>> size, that told heavily against AP2.
>
> AP2 from Mark's slides:
>
>> AP2 (Based on Tab?s latest)
>> - Q.fulfill // lifting
>> - Q() // autolifting, resolve
>> - p.then // deep flattening
>> - p.flatMap // ?chain?

Apologies for being a broken record, but just to make sure the detail
isn't lost in the noise...

AP2 is *almost* right.  If .then() only flattens on the read side,
it's perfect.  The difference is undetectable to code that sticks
strictly with .then(), but it allows for easier composition with
.chain()-based code.

For example, a .then() callback can just return a promise from some
other function.  This other function *could* be returning a nested
promise (it might be a database which can hold promises, for example),
and so a .chain() off of it can usefully just unwrap the DB promise
and deal with the inner promise.  If .then() flattens on the return
side too, this possibility is lost - the unwrapping behavior infects
the chained future regardless of how you interact with it.

I'm ambivalent about whether .flatMap/chain() should be properly
monadic (rejecting the chained promise with a TypeError if you return
a non-promise from the callback) or have the same loose behavior as
.then() where it allows you to return a non-promise and figures out
what you mean.  I lean toward the former because .then() exists
already, but wouldn't die if the latter were chosen.