Promises Consensus

Domenic Denicola domenic at
Wed Jul 31 15:52:26 PDT 2013

From: Mark S. Miller [erights at]

> One thing I think Domenic is missing that I also missed at first: Once we introduce .flatMap, then we need a distinct "accepted" state that is neither "fulfilled" nor "rejected". The issue is that p.then does not fire until the promise p is fulfilled or rejected. If q is pending, and p is accepted to q, then p.flatMap will fire but p.then will not yet fire. When q becomes fulfilled or rejected, then p becomes fulfilled or rejected and p.then fires. Thus, p is following q. So when p and q are both promises, p follows q when p is accepted to q or when p adopts q. This hair splitting goes beyond any previous conversations I've had with anyone, but becomes necessary to account for the behavior or both .flatMap and .then under AP2.

Isn't this just what we've been calling "resolved"? As in "p is resolved q, but still pending because q is pending"?

I suppose that is ambiguous because you could resolve p to a non-promise-like and the behavior is a bit different. Perhaps you're proposing that "resolve p with q" will make p resolved with q, and we will additionally say either that p is accepted with q, if q is a promise-like, or fulfilled with q, if q is non-promise-like. Does that sound accurate?

More information about the es-discuss mailing list