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. 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.
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 th
e 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 o
f > 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 summuri
ze 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
