promises | Communicating Event-Loop Concurrency and Distribution

Kris Zyp kris at
Thu Jan 27 20:23:16 PST 2011

This looks like a case of creating in-language for a library. This was
done with json2.js because it was one of the most widely used libraries
in existence and similar JSON handlers were used in numerous libraries.
The ref_send library and sibling Q style implementations are not
anywhere close to that level of adoption. It seems like there are a
large number of library functions that have proven useful enough (by
real usage) ripe for incorporation into the language before the Q api.
In fact, even with the realm of JavaScript promise libraries, this
implementation/API, which has been discussed and known about for a
number of years has not become the dominate interface API, there are
other approaches that have been found more use. While I certainly like
and appreciate the Q API, I don't think it has proven itself worthy to
be added to the language.

The real pain point with promises isn't that it takes too many
characters to type How many bytes does the average JavaScript
program spend on promise API calls? It negligible, this proposal isn't
solving any real world problem. The main challenge and overhead of
promises, or any CPS-esque code flow is the complexity and overhead of
continuing flow through callbacks. This is why there are proposals for
shorter anonymous functions and single-frame continuations. Single frame
continuations provide the tools for building cleaner, simpler code flow
with promises or any other callback style mechanism without
standardizing on a single library. Like Brendan mentioned in last blog
post (well, I guess it came from Guy Steele), good language empowers
users to build on it, not stifle them with single library approach.


On 1/27/2011 5:09 PM, Mark S. Miller wrote:
> On Thu, Jan 27, 2011 at 8:00 AM, Irakli Gozalishvili <rfobic at
> <mailto:rfobic at>> wrote:
>     Hi,
>     I was curious to know what is the state of the following proposal:
> It's on the agenda for the upcoming March meeting. I was planning to
> do some more work on it before declaring it ready for discussion. But
> since you raise it, I'm happy enough with it in its current state. I
> can clarify my remaining issues with it as discussion proceeds. So
>                      This page is now ready for discussion.
> I do expect that this strawman is too large to be accepted into
> ES-next as a whole. To get some of it accepted -- syntactic sugar +
> some supporting semantics -- we need to find a clean boundary between
> what kernel and extension mechanism the platform needs to provide vs
> the remaining functionality that should be provided by libraries using
> these extension mechanisms. 
> For example, Tyler's web_send uses such an extension API in ref_send
> to stretch these operations onto the network, by mapping them onto
> JSON/RESTful HTTPS operations. Kris Kowal's qcomm library uses
> Q.makePromise (like that proposed above) to stretch these operations
> over WebSockets, whose connection-oriented semantics enables a better
> mapping at the price of more specialized usage. I hope that Kevin
> Reid's caja-captp can also be reformulated as a library extending the
> Q API.
> (See links to ref_send, web_send, qcomm, and caja-captp at the bottom
> of the strawman page.)
>     I do believe that having ES native promises could provide
>     drastically better alternative for writing async code in
>     comparison to currently popular nested callback style. Also even
>     though there are few implementations of Q API adoption is still
>     low IMO that's due to non obvious and verbose syntax. Syntactic
>     sugar described in the proposal really makes a lot of difference.
>     Also I don't see proposal for `Q.when` syntax and would love to
>     know what is the a plan for that.
> Given a lightweight closure syntax, I don't think Q.when actually
> needs any further syntactic sugar. For example, here's the asyncAnd
> example from Figure 18.1 of <> in JS
> with this strawman + destructuring + the lightweight closure syntax
> from HOBD (Harmony of Brendan's Dreams):
>     #asyncAnd(answerPs) {
>         let countDown = answerPs.length;
>         if (countDown === 0) { return true; }
>         const {promise, resolver} = Q.defer();
>         answerPs.forEach(#(answerP) {
>             Q.when(answerP, #(answer) {
>                 if (answer) {
>                     if (--countDown === 0) { resolver(true); }
>                 } else {
>                     resolver(false);
>                 }
>             }, #(ex) {
>                 resolver(Q.reject(ex));
>             });
>         });
>         return promise;
>     }
> The original asyncAnd in Figure 18.1 is in E, whose syntax was
> designed without legacy burden to make such code pleasant.
> Nevertheless, I don't think the code above suffers much in comparison.
> Of course, if you have a suggestion of how a sugared Q.when can
> improve on this enough to be worth the cost of yet more sugar, please
> suggest it. Thanks.
>     Thanks
>     --
>     Irakli Gozalishvili
>     Web:
>     Address: 29 Rue Saint-Georges, 75009 Paris, France
>     <>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at <mailto:es-discuss at>
> -- 
>     Cheers,
>     --MarkM

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

More information about the es-discuss mailing list