> 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.
OK. I'm on board for that. I'm not committing to ES.next, though; IMO, new
features are more important than specifying things that are only de facto
standards but generally working pretty well.
>> 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.
I suppose so.
> 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.
That question is orthogonal.
It's only one instance of a larger question, which is what happens when a host
environment is asked to trigger JS code and it's not obvious which mode to use.
For example, <a onclick="alert(this)">click me</a>. This does not need to be,
and shouldn't be, a problem solved exclusively for setTimeout.
Instead, we will have to deal with this -- as always -- in a way that masks out
specifics of the browser, but deals with the notion of "legacy mode"
evaluation. This is at least in spirit what the purpose of the versioning
strawman is for. There's lots of work left to do there.
>> 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?
Sorry, you're absolutely right there. I was completely overlooking Date.now().
Now, an implementor may not want to have to implement an event queue. I won't
try to speak for implementors. But setTimeout introduces a different overall
program control flow model than the old start-compute-exit model. Most JS
embeddings use the interactive, event queue-based model, but it sounds like at
least Kyle's doesn't.
But that alone should probably not stop us from moving ahead with concurrency.
If an engine wants to provide a sequential JS, they can probably just do so and
say they're conformant with everything except for the concurrency parts. Or
maybe we can highlight the concurrency parts of the spec and say a sequential
JS doesn't have to implement them. This probably isn't too important.
> 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.
You don't need vats for this, just a top-level driver loop.
> Despite the inelegancy, could it work?
No way -- polling isn't just inelegant, it starves your processor. You'd at
least have to expose some sort of sleep() command, no?
>> 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.
Fair enough. Sorry if I was a little hyperbolic.
> 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.
That sounds reasonable. I'll admit to not knowing enough of the complexities of
this subject to really understand if there are any perils of underspecification.
> 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).
No. That's part of my point. We may not be able to standardize the event loop
for ES.next. As I say, I'm open to doing it at some point, and if we add
concurrency features we'll have to specify the event queue as well, but I think
there's a high probability that we won't get to this in time for ES.next. We
have a *lot* on our plate.
> * Standardizing setTimeout based on the event loop is basically just
> adding a timing component to the event loop.
Sure.
> * "Real time is already in ECMAScript 5 through Date.now()"
Right you are.
> * 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 think that's not really relevant. That's an instance of a wider problem, as I
said above.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
