Is "chore" better than "turn"? On Mar 3, 2014 4:10 PM, "Allen Wirfs-Brock" <[email protected]> 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 > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
