On Sat, Mar 19, 2011 at 12:17 PM, Dave Herman <dher...@mozilla.com> wrote:
> These are all good points-- I may not have time to reply this weekend but I
> will.
>
> I just want quickly to point out that despite the wording on
> strawman:strawman ("TC39's response to..."), the vats/promises strawman has
> by no means been agreed upon yet.
>
Good point. FWIW, that line was meant as informal humor, but I see how it
can be misread. Fixed.
> As I say, I believe it's not mature enough to be likely to make the May
> cutoff. I don't even understand what vats are well enough to have an opinion
> yet.
>
As a probability estimate, I agree with this as well. I consider a long
shot, but a shot worth taking. In any case, being on the agenda for May, I
haven't yet invested the time to clarify the text. I hope to do so in April.
>
> I'll reply in more detail when I get a chance.
>
> Thanks,
> Dave
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> David Bruant <david.bru...@labri.fr> wrote:
>
>> Le 19/03/2011 16:39, 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. > > Sorry, I guess I should say, we
>> can't add concurrency without having > it be compatible with existing event
>> queue semantics, which likely > requires formalizing that in Ecma-262. > >>
>> 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>
>> > Yeah, I know. > >> 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. > > Duplicating specs certainly sucks. But it seems
>> nonsensical to me to > specify things that rely on the event queue without
>> having the event > queue in the semantics. Maybe the spec would have to
>> cross-reference > WHATWG? Ugh. > > Actually, wait a minute -- I think I
>> disagree with you here. WHATWG > specifies the specific event queue of the
>> browser. Node.js has its own > event queue. (...) Actually, we agree. I
>> never said that TC39 should copy/paste the event-loop section written by the
>> WHATWG. I said that WHATWG has done some on work specifying what currently
>> happens in browser (joining with your idea of "be[ing] compatible with
>> existing event queue semantics"). One idea would be to see what they've
>> done, get inspired and specify the event queue in ECMAScript. Node.js
>> implementation would be another source of inspiration. But the WHATWG has
>> written a spec, not an implementation which is subject to change at anytime.
>> That's the value I was seeing in particularly studying WHATWG event queue
>> before working on adding event queue to ECMAScript (which, as you say in
>> your next point is compulsory in a way or another to define pre-emption-less
>> concurrency). > I don't think there's any way to specify "run-to-completion"
>> (which is > really just a hand-wavy way of saying "no pre-emption," which is
>> > itself really just a way of saying "sequentialized event queues") >
>> without specifying event queues. > > But I still don't see why standardizing
>> timers, and only timers, is so > important. Node implements them, and they
>> work. What problem are we > fixing? > >> 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). > > Why do you think setTimeout is so special? It seems like just
>> another > host-environment API like, say, onClick. It provides access to one
>> of > the host environment's system service. I agree that it can be
>> considered as an host-environment API. However, setTimeout seems to be
>> widely implemented. I think it makes more sense to specify it within
>> ECMAScript. It could be an occasion to specify what happens when you're in
>> strict mode and you do setTimeout("alert(this)", 0). Is this string
>> interpreted as strict eval code? There is a spec hole here. Bringing
>> setTimeout to ECMAScript would be an occasion to answer the question and not
>> let implementors do whatever they prefer or even to forget the question.
>> This would avoid yet another de facto standard. >> 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. > > How is
>> this element's absence any more important than the absence of, > say,
>> onMouseover? Granted, it has more applicability than just the > browser
>> (since node.js uses it), but as Kyle's already pointed out, > some
>> embeddings may not want to expose the system clock. Actually, a conforming
>> ES5 implementation implements Date.now(). In that condition, it's hard to
>> not expose the system clock, or am I missing something? This is giving me a
>> (terrible) idea to implement setTimeout. We could have two vats. One asks
>> the second to resolve some promise after a certain amout of time. The second
>> loops and resolve the promise when the delay is passed (measured as a delta
>> between Date.now() at request reception and in the loop test. I warned on
>> the terrible aspect of the idea). On resolution, the function passed to
>> Q.when in the first vat is called. Despite the inelegancy, could it work? >>
>> And I intuit it wouldn't be that hard to add it. > > It's not exactly a walk
>> in the park. Have you ever tried to formalize > real time? Einstein had a
>> few words to say about this subject. :-) I am aware of the theorical
>> problem. However, it has never prevented people from including "time" in
>> different languages specifications, or implementing libraries using the
>> concept of "time". There are also people out there writing "performance
>> benchmarks" where they "measure time"! Joke aside, there is no need to
>> formalize real time. For Date.now(), ES5 says: "The now function return a
>> Number value that is the time value designating the UTC date and time of the
>> occurrence of the call to now." About setTimeout and setInterval, WHATWG
>> says: "This API does not guarantee that timers will fire exactly on
>> schedule. Delays due to CPU load, other tasks, etc, are to be expected." In
>> my opinion, these are sufficiently accurate approximations of real time so
>> that implementors can know what to do while admitting they've given up on
>> formalizing real time and don't want to dig any further the topic. > I still
>> just don't get this whole thread. > But I still don't see why standardizing
>> timers, and only timers, is so > important. Node implements them, and they
>> work. What problem are we > fixing? So, to summurize a couple of things that
>> has been said: * With the work on strawman:concurrency, the event loop
>> concept will be added to ECMAScript.next (regardless what is decided for
>> setTimeout). * Standardizing setTimeout based on the event loop is basically
>> just adding a timing component to the event loop. * "Real time is already in
>> ECMAScript 5 through Date.now()" * Standardizing setTimeout is the occasion
>> to fully specify the string-as-a-first argument case to avoid de facto
>> standards before strict mode or Harmony opt-in is widely deployed. I was
>> about to say something about security, but since Mark replied, it will be
>> more acurate to reply to him on the topic. David
>>
>
> _______________________________________________
> 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
