Le 19/03/2011 07:02, David Herman a écrit : > It seems to me there are a couple pieces to Mark's concurrency > proposal. One part is formalizing the event queue that already exists. Is this already done in the current proposal? Because I haven't found it. Regardless, this work of formalizing the already existing event queue has already been done by the WHATWG: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loops I think it would be a mistake to start the formalization work from scratch since a decent part of the work has already been done.
> 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/ Once, I read the concurrency proposal with in mind "can setTimeout be implemented with what is in this proposal?". I have found the timeout section (http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#timeouts) and I thought "awesome!"... until I realized that this example is itself using setTimeout (which is consistently implemented in most ECMAScript-based environments but isn't itself part of any ECMAScript version). ( By the way, there is a typo in this example. I think that "setTimeout(const(){...}, 0)" should be "setTimeout(const(){...}, millis)", where "millis" is the second argument. ) I fully agree that the current proposal and all related work (yours included) offer very powerful mecanisms and solutions to common problems (I had already read your article on "Who says JavaScript I/O has to be ugly?" and really enjoyed what I saw). However, the tiny brick/element/component/part that is missing to implement "time event" ("clock event"?) is to take time into account in the proposal. No matter how powerful the current proposal is, it is lacking this elementary piece in order to implement/standardize setTimeout. And I intuit it wouldn't be that hard to add it. I am not very familiar with promises but from what I understand, having the ability to create a "timed promise" which resolution would be handled by the engine could be a solution. Once again, I'm not familiar with promises, so this idea may sound stupid, but people who are familiar with promises and the Q API will certainly have better ideas on integrating the notion of time to the concept in a way that could make setTimeout and friends implementable on top of this integration. > 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. Does the fact that some event loop formalization work has already been done by the WHATWG within Standard HTML change your opinion on the matter? David > > 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 <mailto: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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
