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 ES.next. 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:
http://blog.mozilla.com/dherman/2011/03/11/who-says-javascript-io-has-to-be-ugly/
http://dherman.github.com/jstask/
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 ES.next, though.
Dave
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
> (http://wiki.ecmascript.org/doku.php?id=strawman:concurrency), 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"
> (http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers).
> Besides the "task" dependency (which is part of the standardized event-loop
> in the same document:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task),
> 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
