On Fri, Jan 28, 2011 at 01:09, Mark S. Miller <erig...@google.com> wrote:
> On Thu, Jan 27, 2011 at 8:00 AM, Irakli Gozalishvili <rfo...@gmail.com>wrote: > >> Hi, >> >> I was curious to know what is the state of the following proposal: >> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency > > > 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. https://github.com/Gozala/vats > >> >> 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 <http://erights.org/talks/thesis/> 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 questions: 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: http://www.jeditoolkit.com/ >> Address: 29 Rue Saint-Georges, 75009 Paris, France<http://goo.gl/maps/3CHu> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
