<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div text="#000000" bgcolor="#ffffff"><blockquote cite="mid:D0920AE7-773F-4C32-8125-6A9EE3162DB2@mozilla.com" type="cite">It seems to me there are a couple pieces to Mark's
      concurrency proposal. One part is formalizing the event queue that
      already exists.</blockquote>
    Is this already done in the current proposal? Because I haven't
    found it. <br></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
    Regardless, this work of formalizing the already existing event
    queue has already been done by the WHATWG:
<a class="moz-txt-link-freetext" href="http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loops">http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loops</a><br></div></blockquote><div><br></div><div>Yeah, I know.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
    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.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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. Others may as well. The unofficial agreement of JS has always been, no matter where you embed it, it should never have pre-emption. So what we would be specifying is the rough concurrency framework required of any JS embedding. In other words, it would be a more abstract specification of event queues, of which WHATWG event queues are a valid implementation.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">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
    (<a class="moz-txt-link-freetext" href="http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#timeouts">http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#timeouts</a>)
    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).</div></blockquote><div><br></div><div>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.</div><div><br></div><div>I still just don't get this whole thread.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">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.</div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">And I intuit it wouldn't be that hard to add it.</div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff"><blockquote cite="mid:D0920AE7-773F-4C32-8125-6A9EE3162DB2@mozilla.com" type="cite"><div>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.</div>
    </blockquote>
    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?<br></div></blockquote><div><br></div><div>Not really, no.</div><div><br></div><div>Dave</div></div><br></body></html>