promises | Communicating Event-Loop Concurrency and Distribution

Irakli Gozalishvili rfobic at
Tue Feb 1 00:19:10 PST 2011

On Fri, Jan 28, 2011 at 01:09, Mark S. Miller <erights at> 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'm familiar with those libraries and actually I have a fork of Kris's
q-comm where I prototyped de-sugared implementation of this proposal for
Mozilla Jetpack, where it will allow cross process async messaging.

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

I see your point, I was actually thinking of an E like syntax, but I do
agree that Q.when is good enough, but then there still should be some
build-in APIs to allowing to build Q.when on top, which leads me to a few

1. Is there supposed to be a build-in type that will represent a promise ?
2. I believe there should be a build-in API to test whether value is promise
or not, how that will look ?
3. There should be build-in API to create / fulfill / brake  promises and
also observe state changes, which will allow lib implementers to implement
Q.when like methods.

Also I think it would be useful to split up proposal into 2 parts:

1. Concentrating on promises and eventual operations
2. vats

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