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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
