Mark S. Miller (2014-02-24T18:11:18.000Z)
domenic at domenicdenicola.com (2014-03-02T22:33:36.930Z)
On Mon, Feb 24, 2014 at 9:45 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > 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. 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?