Re: ES6 Tasks and TaskQueues
Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. It seems to me that the word turn is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken? —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Mar 3, 2014, at 10:04 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: Now its just a word that we are assigning our own meaning to, so we can use turn if we want. But is that equivalence of turn and task really what you're used to, and something whose meaning is intuitive enough? On naming, we can use Turn instead of Task if enough people get it. I like it (much better than longer Activity which is quite vague in comparison, and even better than even longer ECMAScript Task). So +1 for Mark's proposal from me. More substantively, I'm concerned that you don't understand HTML microtasks but conjecture that they can be layered on top of ES tasks. I'm not necessarily faulting you alone here! The HTML specs I've read over the years at whatwg.org are maddeningly strung out and (I think) incomplete in defining tasks and microtasks. Perhaps they are better now. To totally don't understand all the subtleties of HTML tasks and microtasks. But I'm confident that they can be layer above the ES6 tasks because ES 6 really only provides a way to partially order the execution of EStasks and a hook that permits a host to schedule and initiate run to completion calls of EStasks. It the extreme a host could use a single element ES6 task queue and only queue an EStask when it is next to run. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Mon, Mar 3, 2014 at 4:57 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Mar 3, 2014, at 4:32 PM, Mark S. Miller wrote: Is chore better than turn? Mark, to me turn, as a noun, sounds like a scheduling slot rather than the thing that gets scheduled into the slot. For example: in the next turn, we will run the handler for promise p. The thing that gets enqueue is the task of running the handler for promise p rather than the turn in which p get handled. Now its just a word that we are assigning our own meaning to, so we can use turn if we want. But is that equivalence of turn and task really what you're used to, and something whose meaning is intuitive enough? In a time slicing or real-time system, in which future scheduling slots are (even approximately) pre-allocated to specific future times, drawing such a distinction makes sense. But in a run-to-completion event-loop system such as E and JavaScript, I have never found the need for this distinction, and I think it would cause more confusion than it would avoid. The future scheduling slot really has no existence apart from the activity which is scheduled to take place within this slot. The http://erights.org website, several of my papers[1], and papers by others[2] make use of the turn terminology I'm suggesting. I have gotten many questions about many issues over the years about this material, but I have never encountered confusion caused by the choice of the term turn, nor by the absence of a distinction between the scheduling slot and the activity that takes place in this slot. If the authors of some of these other papers have a contrary experience, please post. Thanks. [1] http://research.google.com/pubs/pub40673.html http://research.google.com/pubs/pub35127.html http://erights.org/talks/promises/paper/tgc05.pdf http://erights.org/talks/thesis/markm-thesis.pdf [2] http://soft.vub.ac.be/Publications/2013/vub-soft-tr-13-05.pdf http://www.hpl.hp.com/techreports/2010/HPL-2010-155.html http://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1230context=etd_projects https://www.usenix.org/conference/atc12/technical-sessions/presentation/yoo http://soft.vub.ac.be/~tvcutsem/invokedynamic/presentations/T37_nobackground.pdf https://code.google.com/p/ambienttalk/wiki/EssenceOfAmbientTalk Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache claude.pa...@gmail.com wrote: Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. It seems to me that the word turn is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken? Thanks Claude, this was indeed part of my rationale in choosing the term. Each player in playing a board game engages in activity that occurs over the course of play. But this activity is broken up into a series of turns. Each turn is atomic, and is the unit of interleaving among the activities. The overall activity of any one player can change course over time, in reaction to state changes caused by previous turns. The other reason is more kinesthetic/visual. It plays well with the term event loop, as in each turn is another twist of the event loop. This comes out especially well in some of Tom's diagrams at http://soft.vub.ac.be/~tvcutsem/invokedynamic/presentations/T37_nobackground.pdf —Claude -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
Mark, As I've already said, I can live with Turn. It's big advantage is that it completely avoids confusion with the HTML Task/Micro-task concepts. Allen On Mar 4, 2014, at 8:24 AM, Mark S. Miller wrote: On Mon, Mar 3, 2014 at 4:57 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 3, 2014, at 4:32 PM, Mark S. Miller wrote: Is chore better than turn? Mark, to me turn, as a noun, sounds like a scheduling slot rather than the thing that gets scheduled into the slot. For example: in the next turn, we will run the handler for promise p. The thing that gets enqueue is the task of running the handler for promise p rather than the turn in which p get handled. Now its just a word that we are assigning our own meaning to, so we can use turn if we want. But is that equivalence of turn and task really what you're used to, and something whose meaning is intuitive enough? In a time slicing or real-time system, in which future scheduling slots are (even approximately) pre-allocated to specific future times, drawing such a distinction makes sense. But in a run-to-completion event-loop system such as E and JavaScript, I have never found the need for this distinction, and I think it would cause more confusion than it would avoid. The future scheduling slot really has no existence apart from the activity which is scheduled to take place within this slot. The http://erights.org website, several of my papers[1], and papers by others[2] make use of the turn terminology I'm suggesting. I have gotten many questions about many issues over the years about this material, but I have never encountered confusion caused by the choice of the term turn, nor by the absence of a distinction between the scheduling slot and the activity that takes place in this slot. If the authors of some of these other papers have a contrary experience, please post. Thanks. [1] http://research.google.com/pubs/pub40673.html http://research.google.com/pubs/pub35127.html http://erights.org/talks/promises/paper/tgc05.pdf http://erights.org/talks/thesis/markm-thesis.pdf [2] http://soft.vub.ac.be/Publications/2013/vub-soft-tr-13-05.pdf http://www.hpl.hp.com/techreports/2010/HPL-2010-155.html http://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1230context=etd_projects https://www.usenix.org/conference/atc12/technical-sessions/presentation/yoo http://soft.vub.ac.be/~tvcutsem/invokedynamic/presentations/T37_nobackground.pdf https://code.google.com/p/ambienttalk/wiki/EssenceOfAmbientTalk Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache claude.pa...@gmail.com wrote: Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. It seems to me that the word turn is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken? I agree with Claude and others who feel that turn is confusing - in every outside use of turn as a noun, it refers to the time-slice in which you take actions, not the actions themselves. It is sometimes used slangily to refer to the things you did during the timeslice, like Argh, your turn destroyed my plan, now I've got to think more., but in general using turn to refer to an action feels extremely weird to me. At least for me, this intuition comes from my long experience as a gamer of various sorts - this usage applies equally to card games, board games, video games, etc. I won't die if it ends up getting used, but I'd greatly prefer a different term. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Tue, Mar 4, 2014 at 10:39 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache claude.pa...@gmail.com wrote: Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. It seems to me that the word turn is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken? I agree with Claude and others who feel that turn is confusing Hi Tab, you are reading Claude's message in the opposite way that I am. Hi Claude, which did you mean? - in every outside use of turn as a noun, it refers to the time-slice in which you take actions, not the actions themselves. It is sometimes used slangily to refer to the things you did during the timeslice, like Argh, your turn destroyed my plan, now I've got to think more., but in general using turn to refer to an action feels extremely weird to me. At least for me, this intuition comes from my long experience as a gamer of various sorts - this usage applies equally to card games, board games, video games, etc. I won't die if it ends up getting used, but I'd greatly prefer a different term. ~TJ -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
The benefit of turn is that I've seen this terminology used almost exclusively for denoting an atomic turn of an event loop (tick is also often used). By contrast, terms such as task are used much more broadly (e.g. tasks scheduled on a thread pool). Just my 2c. 2014-03-04 19:47 GMT+01:00 Mark S. Miller erig...@google.com: On Tue, Mar 4, 2014 at 10:39 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache claude.pa...@gmail.com wrote: Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. It seems to me that the word turn is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken? I agree with Claude and others who feel that turn is confusing Hi Tab, you are reading Claude's message in the opposite way that I am. Hi Claude, which did you mean? - in every outside use of turn as a noun, it refers to the time-slice in which you take actions, not the actions themselves. It is sometimes used slangily to refer to the things you did during the timeslice, like Argh, your turn destroyed my plan, now I've got to think more., but in general using turn to refer to an action feels extremely weird to me. At least for me, this intuition comes from my long experience as a gamer of various sorts - this usage applies equally to card games, board games, video games, etc. I won't die if it ends up getting used, but I'd greatly prefer a different term. ~TJ -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Tue, Mar 4, 2014 at 10:47 AM, Mark S. Miller erig...@google.com wrote: On Tue, Mar 4, 2014 at 10:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache claude.pa...@gmail.com wrote: Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. It seems to me that the word turn is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken? I agree with Claude and others who feel that turn is confusing Hi Tab, you are reading Claude's message in the opposite way that I am. Hi Claude, which did you mean? Oh shoot, I think I am. Well then, I disagree with Claude, for the reasons I stated. ^_^ ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Mar 4, 2014, at 11:03 AM, Tom Van Cutsem wrote:
The benefit of turn is that I've seen this terminology used almost
exclusively for denoting an atomic turn of an event loop (tick is also
often used). By contrast, terms such as task are used much more broadly
(e.g. tasks scheduled on a thread pool). Just my 2c.
I think we can think of the entire scheduling mechanism described in the ES6
spec. as an event loop in the sense you use the term, but the terminology get
complicated by the fact the we will ultimately have (HTML today, ES in the
future) a user level Event abstraction and that some of the (turns, tasks,
whatever ) scheduled via by the ES6 spec. mechanism will run Event handlers
for the user level Event abstraction while other ('turns, tasks, etc.) won't
have anything to do with that abstraction.
So, we move the potential for confusion from between HTML and ES Tasks to
confusion between ES Language level Events and ES engine level events.
Allen
2014-03-04 19:47 GMT+01:00 Mark S. Miller erig...@google.com:
On Tue, Mar 4, 2014 at 10:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache claude.pa...@gmail.com wrote:
Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock al...@wirfs-brock.com a écrit
:
I don't think this use of the word turn is broadly enough known to
provide many spec. readers an immediate intuitive feeling for the concept.
It seems to me that the word turn is widely used in that sense for
turned-based games such as chess, so that it has a good chance to be
understood. Or am I mistaken?
I agree with Claude and others who feel that turn is confusing
Hi Tab, you are reading Claude's message in the opposite way that I am.
Hi Claude, which did you mean?
- in
every outside use of turn as a noun, it refers to the time-slice in
which you take actions, not the actions themselves. It is sometimes
used slangily to refer to the things you did during the timeslice,
like Argh, your turn destroyed my plan, now I've got to think more.,
but in general using turn to refer to an action feels extremely
weird to me.
At least for me, this intuition comes from my long experience as a
gamer of various sorts - this usage applies equally to card games,
board games, video games, etc.
I won't die if it ends up getting used, but I'd greatly prefer a different
term.
~TJ
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Tue, Mar 4, 2014 at 2:03 PM, Tom Van Cutsem tomvc...@gmail.com wrote: The benefit of turn is that I've seen this terminology used almost exclusively for denoting an atomic turn of an event loop (tick is also often used). I was drafting a response that said exactly this, came back from lunch and Tom's post was here. Pardon the dog piling, but +1. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
Le 4 mars 2014 à 19:47, Mark S. Miller erig...@google.com a écrit : On Tue, Mar 4, 2014 at 10:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Mar 4, 2014 at 5:59 AM, Claude Pache claude.pa...@gmail.com wrote: Le 24 févr. 2014 à 19:40, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. It seems to me that the word turn is widely used in that sense for turned-based games such as chess, so that it has a good chance to be understood. Or am I mistaken? I agree with Claude and others who feel that turn is confusing Hi Tab, you are reading Claude's message in the opposite way that I am. Hi Claude, which did you mean? I just meant that, since turn is a term widely used in context of turn-based games, it would be understood even by non-native speakers. Effectively, turn refers to the time-slice rather than to the actions taken during that time, as Tab says; but since I didn't considered what is exactly an ECMAScript task, I cannot say if that would be confusing. —Claude - in every outside use of turn as a noun, it refers to the time-slice in which you take actions, not the actions themselves. It is sometimes used slangily to refer to the things you did during the timeslice, like Argh, your turn destroyed my plan, now I've got to think more., but in general using turn to refer to an action feels extremely weird to me. At least for me, this intuition comes from my long experience as a gamer of various sorts - this usage applies equally to card games, board games, video games, etc. I won't die if it ends up getting used, but I'd greatly prefer a different term. ~TJ -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
Tom Van Cutsem wrote: By contrast, terms such as task are used much more broadly (e.g. tasks scheduled on a thread pool). Yes, and a Task (e.g., in Rust; akin to goroutine in Go or Process in Erlang) can be suspended voluntarily. The use of task goes way back (multi-tasking). I think we want a different word, not only to avoid confusion with respect to HTML5, but because JS event loop runs or turns really are different from those other tasks from CS literature and OS/PL research. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: ES6 Tasks and TaskQueues
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: - 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. - 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. - 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. Perhaps we can flip this around: - What would an example implementation look like, wherein ES tasks are different from HTML micro-tasks? - 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 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. From: es-discuss es-discuss-boun...@mozilla.org on behalf of Allen Wirfs-Brock al...@wirfs-brock.com Sent: Monday, February 24, 2014 13:40 To: Mark S. Miller Cc: es-discuss@mozilla.org list Subject: Re: ES6 Tasks and TaskQueues On Feb 24, 2014, at 10:11 AM, Mark S. Miller wrote: On Mon, Feb 24, 2014 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.commailto:al...@wirfs-brock.com wrote: ... Hi Allen, I agree that it's good to keep these levels separate by adopting distinct terminology. However, using the term Task to avoid confusion with html's use of adjective-Task does not seem like a good strategy. I am not surprised this causes more confusion than it avoids. I suggest that the priority-independent EcmaScript level concept be called Turn, as it has exactly the semantics of a turn: It is a run-to-completion unit of execution that goes from an empty user-stack to an empty user-stack. Yes, that potential confusion has also been a concern. That's why in this message I starting calling them EMAScript Tasks, similarly to how the ES spec. uses EMCAScript function to talk about functions implemented using ECMAScript code rather than the broader category of all functions. My second choice, if ECMAScript Task proves to be untenable would be Activity. I'm not too fond of turn, although I know it is a term that you favor. I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. Also, there might be some verb/noun confusion for non-native English speakers. But, in the end I'll be fine with using whatever term TC39 favors. Are ECMAScript 6 Tasks insufficient support the HTML or other browser requirements? Not as far as I know, but please let me know if you think something interferes with those requirements. ES Tasks are not intended to support all activity scheduling that might take place in a complex platform but only activities that involve the synchronous (to the activity) execution of ES code. I was with you till this point. But did you mean to say synchronous rather than asynchronous above? I was afraid that might be confusing which is my I added the parenthetical qualifier. I was referring to the synchronous relative FIFO ordering within a single TaskQueue. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
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
Re: ES6 Tasks and TaskQueues
Is chore better than turn? On Mar 3, 2014 4:10 PM, Allen Wirfs-Brock al...@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
Re: ES6 Tasks and TaskQueues
On Mar 3, 2014, at 4:32 PM, Mark S. Miller wrote: Is chore better than turn? Mark, to me turn, as a noun, sounds like a scheduling slot rather than the thing that gets scheduled into the slot. For example: in the next turn, we will run the handler for promise p. The thing that gets enqueue is the task of running the handler for promise p rather than the turn in which p get handled. Now its just a word that we are assigning our own meaning to, so we can use turn if we want. But is that equivalence of turn and task really what you're used to, and something whose meaning is intuitive enough? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
Allen Wirfs-Brock wrote: Now its just a word that we are assigning our own meaning to, so we can use turn if we want. But is that equivalence of turn and task really what you're used to, and something whose meaning is intuitive enough? On naming, we can use Turn instead of Task if enough people get it. I like it (much better than longer Activity which is quite vague in comparison, and even better than even longer ECMAScript Task). So +1 for Mark's proposal from me. More substantively, I'm concerned that you don't understand HTML microtasks but conjecture that they can be layered on top of ES tasks. I'm not necessarily faulting you alone here! The HTML specs I've read over the years at whatwg.org are maddeningly strung out and (I think) incomplete in defining tasks and microtasks. Perhaps they are better now. Who will understand both HTML and ES6 draft and make sure your conjecture is true? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ES6 Tasks and TaskQueues
I was going to respond via github to this issue comment, but I figured the answer probably was of interest to a broader audience. So go and read https://github.com/Raynos/observ-hash/issues/2#issuecomment-35857671 and then continue. Rev22 of the ES6 draft introduced the concepts of Tasks and TaskQueues: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tasks-and-task-queues. A Task is a non-interruptable, run to completion activity within the ECMAScript execution environment that typically includes the evaluation of ECMAScript code. A TaskQueue is a FIFO queue of Tasks that are waiting to run. Tasks were added to ES6 in support of Promises. They are also useful for describing the execution sequences of top level scripts and hopefully other features that may be added post ES6. Rev22 defines two built-in tasks queues A queue for promise tasks and a queue for script evaluation tasks. Other task queues may be added in the future and an host platform may defined additional task queues and new kinds of tasks. The ES6 spec. does not define a complete scheduling algorithm for tasks, instead it says: The PendingTask records from a single Task Queue are always initiated in FIFO order. This specification does not define the order in which multiple Task Queues are serviced. An ECMAScript implementation may interweave the FIFO evaluation of the PendingTask records of a Task Queue with the evaluation of the PendingTask records of one or more other Task Queues. An implementation must define what occurs when there are no running execution context and all Task Queues are empty. Are Tasks the same as HTML Micro-tasks? Why are these called Tasks and not micro-tasks. I intentionally didn't use the term micro-task to avoid confusion with HTML's use of that term. It's probably best to talk about the things called Tasks in the ES6 spec. as ECMAScript Tasks. Micro-task (and Task, I believe) have specific meaning and semantics within the context of HTML. I don't want to build the HTML semantics into the ES spec. because ES is also used in other platforms besides the browser/HTML environment. The expectation is that such platforms can use ECMAScript Tasks, TaskQueues, and platform specific scheduling rules to define the behavior of activities they push to the ES execution environment. Are ECMAScript 6 Tasks insufficient support the HTML or other browser requirements? Not as far as I know, but please let me know if you think something interferes with those requirements. ES Tasks are not intended to support all activity scheduling that might take place in a complex platform but only activities that involve the synchronous (to the activity) execution of ES code. Task queues are used to enforce necessary relative serialization of certain activities. The set of available task queues, their sizes (could be 1), and their relative scheduling order are left completely up to the host platform. Also, there is nothing that says a platform can't have another higher level scheduling mechanism (I'm thinking about mutator events here) that is used to populate ES Task Queues. ES Tasks/TaskQueues are so basic it hard for me to see how they would limit a host platform. But, let me know if you see a problem. Do ES Tasks have a ES API? Not currently. It would be easy enough to define an API for enqueing the invocation of an ES function as a ES Task. Also you can imagine APIs for defining TaskQueues and setting scheduling policies for TaskQueues. That is all post ES6 work and requires somebody to develop proposals and champion them. If HTML (or any other platform) is considering defining a capability like that (which isn't in other ways semantically couple to that platform) it would be nice to see it done as a ES feature proposal. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
On Mon, Feb 24, 2014 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: I was going to respond via github to this issue comment, but I figured the answer probably was of interest to a broader audience. So go and read https://github.com/Raynos/observ-hash/issues/2#issuecomment-35857671 and then continue. Rev22 of the ES6 draft introduced the concepts of Tasks and TaskQueues: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tasks-and-task-queues. A Task is a non-interruptable, run to completion activity within the ECMAScript execution environment that typically includes the evaluation of ECMAScript code. A TaskQueue is a FIFO queue of Tasks that are waiting to run. Tasks were added to ES6 in support of Promises. They are also useful for describing the execution sequences of top level scripts and hopefully other features that may be added post ES6. Rev22 defines two built-in tasks queues A queue for promise tasks and a queue for script evaluation tasks. Other task queues may be added in the future and an host platform may defined additional task queues and new kinds of tasks. The ES6 spec. does not define a complete scheduling algorithm for tasks, instead it says: The PendingTask records from a single Task Queue are always initiated in FIFO order. This specification does not define the order in which multiple Task Queues are serviced. An ECMAScript implementation may interweave the FIFO evaluation of the PendingTask records of a Task Queue with the evaluation of the PendingTask records of one or more other Task Queues. An implementation must define what occurs when there are no running execution contexthttp://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-execution-contextsand all Task Queues are empty. Are Tasks the same as HTML Micro-tasks? Why are these called Tasks and not micro-tasks. No, for the reason you state below. HTML's division of activities into Tasks, micro-Tasks, etc, assumes a particular priority relationship. EcmaScript is trying to be more general, to allow this and other priority relationships at the choice of hosting environment. I intentionally didn't use the term micro-task to avoid confusion with HTML's use of that term. It's probably best to talk about the things called Tasks in the ES6 spec. as ECMAScript Tasks. Micro-task (and Task, I believe) have specific meaning and semantics within the context of HTML. I don't want to build the HTML semantics into the ES spec. because ES is also used in other platforms besides the browser/HTML environment. The expectation is that such platforms can use ECMAScript Tasks, TaskQueues, and platform specific scheduling rules to define the behavior of activities they push to the ES execution environment. Hi Allen, I agree that it's good to keep these levels separate by adopting distinct terminology. However, using the term Task to avoid confusion with html's use of adjective-Task does not seem like a good strategy. I am not surprised this causes more confusion than it avoids. I suggest that the priority-independent EcmaScript level concept be called Turn, as it has exactly the semantics of a turn: It is a run-to-completion unit of execution that goes from an empty user-stack to an empty user-stack. Are ECMAScript 6 Tasks insufficient support the HTML or other browser requirements? Not as far as I know, but please let me know if you think something interferes with those requirements. ES Tasks are not intended to support all activity scheduling that might take place in a complex platform but only activities that involve the synchronous (to the activity) execution of ES code. I was with you till this point. But did you mean to say synchronous rather than asynchronous above? Task queues are used to enforce necessary relative serialization of certain activities. The set of available task queues, their sizes (could be 1), and their relative scheduling order are left completely up to the host platform. Also, there is nothing that says a platform can't have another higher level scheduling mechanism (I'm thinking about mutator events here) that is used to populate ES Task Queues. ES Tasks/TaskQueues are so basic it hard for me to see how they would limit a host platform. But, let me know if you see a problem. Do ES Tasks have a ES API? Not currently. It would be easy enough to define an API for enqueing the invocation of an ES function as a ES Task. Also you can imagine APIs for defining TaskQueues and setting scheduling policies for TaskQueues. That is all post ES6 work and requires somebody to develop proposals and champion them. If HTML (or any other platform) is considering defining a capability like that (which isn't in other ways semantically couple to that platform) it would be nice to see it done as a ES feature proposal. Allen ___ es-discuss mailing list
Re: ES6 Tasks and TaskQueues
On Feb 24, 2014, at 10:11 AM, Mark S. Miller wrote: On Mon, Feb 24, 2014 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: ... Hi Allen, I agree that it's good to keep these levels separate by adopting distinct terminology. However, using the term Task to avoid confusion with html's use of adjective-Task does not seem like a good strategy. I am not surprised this causes more confusion than it avoids. I suggest that the priority-independent EcmaScript level concept be called Turn, as it has exactly the semantics of a turn: It is a run-to-completion unit of execution that goes from an empty user-stack to an empty user-stack. Yes, that potential confusion has also been a concern. That's why in this message I starting calling them EMAScript Tasks, similarly to how the ES spec. uses EMCAScript function to talk about functions implemented using ECMAScript code rather than the broader category of all functions. My second choice, if ECMAScript Task proves to be untenable would be Activity. I'm not too fond of turn, although I know it is a term that you favor. I don't think this use of the word turn is broadly enough known to provide many spec. readers an immediate intuitive feeling for the concept. Also, there might be some verb/noun confusion for non-native English speakers. But, in the end I'll be fine with using whatever term TC39 favors. Are ECMAScript 6 Tasks insufficient support the HTML or other browser requirements? Not as far as I know, but please let me know if you think something interferes with those requirements. ES Tasks are not intended to support all activity scheduling that might take place in a complex platform but only activities that involve the synchronous (to the activity) execution of ES code. I was with you till this point. But did you mean to say synchronous rather than asynchronous above? I was afraid that might be confusing which is my I added the parenthetical qualifier. I was referring to the synchronous relative FIFO ordering within a single TaskQueue. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
