Promises Consensus

Mark Miller erights at
Wed Jul 31 15:57:38 PDT 2013

On Wed, Jul 31, 2013 at 3:52 PM, Domenic Denicola <
domenic at> wrote:

> 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'm sorry Domenic, but since I'm hair splitting and stated several
distinctions, I need to know which "this" you refer to.

> 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?
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Text by me above is hereby placed in the public domain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list