ES6 Tasks and TaskQueues

[Mark S. Miller]

Is "chore" better than "turn"?
 On Mar 3, 2014 4:10 PM, "Allen Wirfs-Brock" <allen at wirfs-brock.com> wrote:

>
> On Mar 3, 2014, at 1:55 PM, Domenic Denicola wrote:
>
> I'd like some help understanding why we are not using the word
> "micro-tasks" here, and more generally why we are going our separate way
> and not trying to unify with HTML. Here is my understanding:
>
>
> I've specifically avoided the word "micro-task" because I'm not trying to
> specify all (really any) of the semantics of HTML micro-tasks.  ES6 only
> needs to specify enough "multi-tasking" semantics to enable the
> specification of promises and the sequential evaluation of  multiple
> scripts.  In addition, I'm providing primitives that HTML or other host
> platforms might use to express the semantics of their own multi-tasking
> abstractions that trigger execution of ES code.
>
>
> - ES tasks are, essentially, purposefully under-specified versions of HTML
> micro-tasks. (That is, they have many unspecified behavior hooks, but a
> conformant HTML micro-task implementation will be a conformant ES task
> implementation that fills in those gaps.) They agree on all features,
> including the multiple queues, FIFO ordering requirements, empty-stack
> invocation, etc.
>
>
> I don't know whether this is true or not.  I don't have a deep
> understanding of HTML micro-task and did not base what is in the ES6 spec.
> on them. Instead, I provided a small set of fundamental mechanisms that can
> be used to specify the sequencing of ES code execution.  If what I ended up
> is an under specified version of HTML micro-tasks it sounds like I'm on the
> right track and that there are things that HTML needs to specify that are
> currently not needed by ES or possibly other host platforms.
>
>
> - All implementers whose engines include HTML micro-tasks will be using
> the same code for ES tasks and HTML micro-tasks. There may be some engines
> which do not include HTML micro-tasks---or something that meets that spec's
> requirements, but under a different name---however, I am not aware of them.
>
>
> How browsers factor their implementations isn't really my concern.  But I
> an concerned about unnecessarily coupling the Es spec. with HTML. HTML is
> absolutely the most important host for ES, but it isn't the only one now or
> in the future.
>
> - Even if an implementer, which did not a priori implement HTML
> micro-tasks, were to create an implementation of ES tasks, that implementer
> would need to fill out the missing underspecified details, which would lead
> them to something probably exactly like HTML micro-tasks.
>
>
> Which details do you think are missing in this regard? There are a couple
> specific things that the spec. says a host or implementation must define
> (what happens when all queues are empty, the relative sequencing of script
> and promise task queues).  If we have consensus on a single universal
> answer to these we could specify it.  Otherwise, its best left to
> implementations and future editions of the ES spec.
>
>
>
> Perhaps we can flip this around:
>
> - What would an example implementation look like, wherein ES tasks are
> different from HTML micro-tasks?
>
>
> So is this the specification of "micro-tasks" I should be looking at:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-4?
> If so there seems to be all sorts of stuff in there that is very specific
> to browsers.  It's basically
>
> Using the ES6 spec Task primitives, I  could easily provide
> implemention-defined spec. pieces necessary  for an ES implementation that
> just runs an externally provided script and services promises and it would
> be much simpler than the HTML processing model. It would basically be:
> Perform the single task in the LoadingTasks queue and then process the
> tasks in the PromiseTasks queue until it is empty.  Then terminate.
>  Probably need to add a a few works about what to do in the event that a
> task terminates via an uncaught exception.
>
> I think the more interesting exercise would be to tweak the  webapps spec.
> so that it used the ES6 primitives for actual ES code execution.
>
> - Given that example, do we want to encourage such an implementation to
> exist? That seems to be what the two competing specs are doing.
>
>
> I'd say yes.  I expect a command line ES engine to have a much simpler
> task processing model than a browser.
>
>
> I find it unnecessarily confusing that both ES and HTML are speccing out
> the same mechanism, with very many of the same features, and then
> pretending they are distinct. When in reality, i.e. in implementations,
> they are not going to be distinct at all---they are going to be exactly the
> same code, and nobody knows what to name the variables in that code because
> there are two competing specs with their own names for each concept.
>
>
> I certainly don't want to double specify anything.  It seems to me, that
> the right division of labor is for ES to specific only the mechanism by
> which the execution of ES code can be initiated along with low level
> coordination mechanisms necessary to support actual control abstractions
> that exist in ES (ie Promises).  Other specifications should add platform
> specific policies using  those mechanisms and define control abstractions
> that aren't part of ES. Most of what is in HTML's processing model are
> platform policy issues of this sort.
>
> If/when ES adds new language/library abstractions such as events or a user
> level task abstraction, then the ES spec would provide the necessary
> semantics, just like it is doing for promises.
>
> BTW, I think I've found a conflict free word we could use instead of
> "ECMAScript task" its "chore".  An ugly word but it seems to be available.
>
> Allen
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140303/e3dd70d4/attachment.html>