Promises Consensus with /A+ terminology

Mark S. Miller erights at
Thu Aug 1 11:27:14 PDT 2013

On Thu, Aug 1, 2013 at 10:00 AM, Tab Atkins Jr. <jackalmage at>wrote:

> On Thu, Aug 1, 2013 at 9:09 AM, Anne van Kesteren <annevk at>
> wrote:
> > On Thu, Aug 1, 2013 at 5:07 PM, Anne van Kesteren <annevk at>
> wrote:
> >> I basically took Tab's email and rewrote the terminology. I omitted
> >> the issues for brevity. Hopefully this helps.
> Sorry, I was waiting until Mark and Domenic had finished up their
> terminology discussion before I did a third rewrite.
> > Having done that. I wonder if we could leave the monad part out for
> > now. As Mark pointed out in the other thread it causes a bunch of
> > headaches to get that correct, and since we already decided (I
> > believe) to not break with existing practice we could ship the subset
> > that is that and figure out the superset-promise-that-works-for-monads
> > later. That might also give us some insight into how many people will
> > want to wrap promises to make the monad-suitable.
> Let's not reopen this, please.

There are three questions here, which need to be settled in roughly this
chronological order:
1) What should tc39 do quickly, to unblock the DOM's need for promises and
avoid a design fork?
2) What should DOM do quickly the tc39's quick output?
3) Once #1 and #2 are settled, what should tc39 do for es7?

For #1 I agree with Tab. We should not reopen this issue, but should rather
proceed to settle the AP2ish design quickly. Otherwise we won't settle
anything quickly and DOM will go their own way.

For #2, since whatever DOM does quickly becomes a compat constraint on all
future decisions, DOM should take the minimum subset of #1 which actually
meets their short term needs. I leave it to those who understand those
needs to argue about what these are.

For #3, we will hopefully stay upwards compat with both #1 and #2. But
compat with #2 will be more pressing, as that will have been massively
deployed as part of the browser.

>  The way I've outlined things means
> that then()-based stuff works compatibly with the existing spec, so
> that's not a concern.  We've already had long threads about why nested
> promises are useful (namely, that "promise" in practice isn't a single
> type - you have multiple types of promises from different promise
> sources, and don't always want to smash them together).

These have been long threads so I won't rehash them either. However, I will
point out that these long threads also explain why nested promises won't be

> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at

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

More information about the es-discuss mailing list