Bringing setTimeout to ECMAScript

David Herman dherman at
Fri Mar 18 23:02:17 PDT 2011

It seems to me there are a couple pieces to Mark's concurrency proposal. One part is formalizing the event queue that already exists. Another part is introducing new concepts and features to the language (like promises and vats).

I want to hear what Mark has to say at the TC39 meeting, but my gut tells me it's too early to introduce new concurrency constructs for There's actually a lot you can do with closures and objects (such as the promises libraries people have been experimenting with lately). And with generators, you can implement some really convenient constructs. I've recently been building a concurrency library called jsTask, that makes it possible to write blocking computations in a really natural style:

As for event queue semantics, I think in principle that Ecma-262 is a reasonable place to specify it. It doesn't rely on specifics of the browser, and Node.js is a testament to that. (Besides, a non-interactive setting could probably be modeled as a trivial event queue, i.e. one with just a single "run the program" event.) I'm not sure whether this is worth trying to accomplish in time for, though.


On Mar 18, 2011, at 5:51 AM, David Bruant wrote:

> Hi,
> _Foreword_
> Each time I write "setTimeout", I mean "setTimeout and setInterval (and there clear functions)" (please forgive the recursive flaw)
> _Introduction_
> Before the concurrency proposal (, a pure ECMAScript program had a start and an end, that was it. No event loop, no asynchronous callback, etc.
> If ECMAScript standardizes this proposal or another, there will be a need to standardize an event loop in a way or another. Adding a timing aspect to this event loop and setTimeout can be standardized in ECMAScript.
> _Current_standardization_state_
> setTimeout isn't part of ECMAScript. setTimeout is nonetheless standardized as part of "HTML Standard" ( Besides the "task" dependency (which is part of the standardized event-loop in the same document:, this is more or less ECMAScript.
> _Current_use_
> As anyone will have certainly noticed, setTimeout has no reason to be considered as client-side web specific. And, as a matter of fact, there is a setTimeout in node.js and in ActionScript apparently. I wouldn't be surprised if most (if not all) ECMAScript-based languages had a setTimeout function consistently.
> For all these reasons, I am wondering if setTimeout wouldn't be had being standardized in ECMAScript itself.
> _How?_
> I currently see two main tracks:
> * Standardize it as it is.
> * Standardize a more powerful mecanism and standardize setTimeout as an implementation based on this mecanism. If setTimeout had been considered as not flexible enough by some people, this could be an occasion to fit their use case (I personnally have no suggestion on the matter)
> I am not familiar with promises, but after reading a bit about it and seeing a presentation on the topic, I intuit that it may not be very difficult to add a timing aspect to it based on which setTimeout could be implemented.
> _Advantages_
> * As said, it could be an occasion to fix flexibility issues that people would find to setTimeout
> * Define a strict mode behavior to it. Currently, people can pass strings as first argument to setTimeout. There       is currently a spec hole in what happens in strict mode for setTimeout. 
> I would be in favor to throw an exception if people use strings in setTimeout in strict mode (maybe it's too late to suggest that since FF4 ships in less than a week?). Anyway, there is room for other ideas like standardizing strict eval for strings as first argument in strict mode. My main goal is to discuss the issue.
> I haven't found any trace of previous discussion of this topic. Has there been any?
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at

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

More information about the es-discuss mailing list