forbes at lindesay.co.uk (2013-07-31T23:34:33.026Z)
For some meaning of ok, yes. It is clear that the DOM folks are proceeding full speed with promises, but are willing to be compat with a tc39 consensus if a tc39 consensus can be formed quickly enough. It was clear from the May tc39 meeting that promises that did not support promises-for-promises could not achieve consensus fast enough to serve this purpose. Due to Tab's very clever AP2 proposal, those who want to live in a .then world without promises-for-promises can (for most purposes) effectively do so. While the existence of .flatMap/.accept satisfies those who insist that a more purely monadic view, supporting promises-for-promises be exposed. Nothing that has happened since then changes my opinion of the technical merits of the case. Five years from now we will look back and wish these two styles had simply been two distinct abstractions that had nothing to do with each other. But with the AP2 design, the costs of supporting both styles in one API are minimized. Tab did a great job finding a livable compromise. We are on track for agreeing on something in time to avoid a design fork by DOM promises.
On Wed, Jul 31, 2013 at 12:48 PM, Juan Ignacio Dopazo <dopazo.juan at gmail.com > wrote: > Does this all mean that you're ok with having promises-for-promises? > > For some meaning of ok, yes. It is clear that the DOM folks are proceeding full speed with promises, but are willing to be compat with a tc39 consensus if a tc39 consensus can be formed quickly enough. It was clear from the May tc39 meeting that promises that did not support promises-for-promises could not achieve consensus fast enough to serve this purpose. Due to Tab's very clever AP2 proposal, those who want to live in a .then world without promises-for-promises can (for most purposes) effectively do so. While the existence of .flatMap/.accept satisfies those who insist that a more purely monadic view, supporting promises-for-promises be exposed. Nothing that has happened since then changes my opinion of the technical merits of the case. Five years from now we will look back and wish these two styles had simply been two distinct abstractions that had nothing to do with each other. But with the AP2 design, the costs of supporting both styles in one API are minimized. Tab did a great job finding a livable compromise. We are on track for agreeing on something in time to avoid a design fork by DOM promises. _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/99905f0a/attachment.html>