ES6 Tasks and TaskQueues

[Domenic Denicola]

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-bounces at mozilla.org> on behalf of Allen Wirfs-Brock <allen at wirfs-brock.com>
Sent: Monday, February 24, 2014 13:40
To: Mark S. Miller
Cc: es-discuss at 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 <allen at wirfs-brock.com<mailto:allen at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140303/dd69cfc1/attachment.html>