Why not Profiles? (was: Bringing setTimeout to ECMAScript)

Mark S. Miller erights at google.com
Sun Mar 20 09:14:55 PDT 2011


On Sun, Mar 20, 2011 at 8:56 AM, David Herman <dherman at mozilla.com> wrote:

> > 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.


I like this approach, so much that I changed the subject line ;). It gets us
back into a practice that tc39 had and dropped before I joined, defining
subsets or "profiles" of the full language as normative specs one could
conform to. My SES work is essentially such a profile. Some CommonJS folks
are considering requiring all CommonJS modules to be compat with ES5/strict,
and treating them as such whether they say "use strict" or not. A
server-side engine that dropped support for non-strict code could be much
simpler. All of these seem like sensible profiles to give normative names
to.

So I was wondering, why has our common wisdom become to avoid standard
profiles? Do these reasons apply to such cases?




> 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110320/ef84e0b1/attachment-0001.html>


More information about the es-discuss mailing list