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> 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/20140224/1eb93d38/attachment.html>

On Feb 24, 2014, at 10:11 AM, Mark S. Miller wrote:

> 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.

> 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.