yield and Promises

David Herman dherman at mozilla.com
Fri Oct 21 10:01:46 PDT 2011

Hi Kris,

Your proposal has a lot of similarities to


which was proposed this past spring.

I'm not sure I follow what's top-down vs bottom-up about the two different approaches. Let me suggest some terminology that has emerged in the proposal process: I'll use "generators" to mean any single-frame, one-shot continuation feature that's independent of the host event queue, and "deferred functions" to mean any single-frame, one-shot continuation feature that is tied to the host event queue by means of being automatically scheduled.

> Generators directly solve a problem that is much less significant in normal JS coding. While it is exciting that generators coupled with libraries give us a much better tool for asynchronous use cases (the above can be coded with libraryFunction(function*(){...}), my concern is that the majority use case is the one that requires libraries rather than the minority case, and does not promote interoperability. 

It's true that generators require libraries in order to use them for writing asynchronous code in direct style. And I agree with you and Alex and Arv that there is a cost to not standardizing on those libraries. There are different frameworks with similar but incompatible idioms for Deferred objects, Promises, and the like, and they could be standardized.

> A couple years later, I believe the landscape has dramatically changed, and we indeed do have significant convergence on a promise API with the "thenable" interface. From Dojo, to jQuery, to several server side libraries, and apparently even Windows 8's JS APIs (from what I understand) all share an intersection of APIs that include a then() method as a method to define a promise and register a callback for when a promise is fulfilled (or fails). This is an unusual level of convergence for a JS community that is so diverse. I believe this gives evidence of well substantiated and tested interface that can be used for top-controlled single-frame continuations that can easily be specified, understood and used by developers.

But there's more to it than just the interface. You fix a particular scheduling semantics when you put deferred functions into the language. I'm still learning about the difference between the Deferred pattern and the Promises pattern, but the former seems much more stateful than the latter: you enqueue another listener onto an internal mutable queue. I'm not sure how much state can be avoided with listeners (at the end of the day, callbacks have to be invoked in some particular order), but that concerned me when I saw the deferred functions proposal. I can't prove to you that that scheduling policy isn't the right one, but I'm not ready to say it is.

So I'm not sure all scheduling policies are created equal. And with generators, at least people have the freedom to try out different ones. I'm currently trying one with task.js, and I hope others will try to come up with their own. (There's also the added benefit that by writing the scheduler in JS, you can instrument and build cool tools like record-and-reply debugging.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111021/dc5323a6/attachment-0001.html>

More information about the es-discuss mailing list