promises | Communicating Event-Loop Concurrency and Distribution

Mark S. Miller erights at
Thu Jan 27 21:37:28 PST 2011

On Thu, Jan 27, 2011 at 8:23 PM, Kris Zyp <kris at> wrote:

>  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.

Hi Kris, I appreciate your other points. However, from my own experience
having programmed in this style with syntactic support, and attempting to
bring myself to program in this style without syntactic support, I disagree.
In this particular case, the syntactic difference between, "foo", [b, c])


   a ! foo(b, c)

makes a tremendous difference in one's willingness to use these
abstractions, and in one's ability to read and understand code expressed in
these abstractions. I believe this difference is adequate to deter most
usage -- even in my experience by people like me, who already like these

> 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.

I don't understand why single-frame continuations are not at least as
vulnerable to the criticism you make above. They are even more unproven
among JavaScript programmers than are the concurrency abstractions in the
strawman. The main benefit of moving support for single-frame
continuations into the language is notational, which you dismiss above. I
don't get it.

And in case you missed it, I am *not* proposing that we bake in any one
library for remote communications, whether web_send, qcomm, or captp. I am
hoping for an extension API that would allow library authors to create an
open ended set of remote communications libraries that plug into this
extension API. As I understood your previous engagement with these issues, I
thought you were also focussed on such extensibility.

> Thanks,
> Kris
> On 1/27/2011 5:09 PM, Mark S. Miller wrote:
> On Thu, Jan 27, 2011 at 8:00 AM, Irakli Gozalishvili <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
> --
>     Cheers,
>     --MarkM

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

More information about the es-discuss mailing list