Re: Final iterator spec
On Sun 02 Mar 2014 04:18, Domenic Denicola dome...@domenicdenicola.com writes: You can just do `if (Symbol.iterator in potentialIterable)`. Of course, this can introduce time-of-check-to-time-of-use bugs. Actually calling @@iterator on the iterable is more reliable. Andy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Final iterator spec
Le 03/03/2014 10:11, Andy Wingo a écrit :
On Sun 02 Mar 2014 04:18, Domenic Denicola dome...@domenicdenicola.com writes:
You can just do `if (Symbol.iterator in potentialIterable)`.
Of course, this can introduce time-of-check-to-time-of-use bugs.
Actually calling @@iterator on the iterable is more reliable.
This only shifts the problem one step without really solving it. Calling
@@iterator may return a non-iterator or may return something that looks
like a iterator ('next' method), but throws when calling 'next'.
I wonder if time-of-check-to-time-of-use bugs can be fully avoided
entirely in JS?
It might be possible to guarantee some properties in TypeScript assuming
all consummers of a piece of code are checked by the TypeScript compiler.
In practice, it looks like JS devs have lived well with solution like
Domenic's one.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.of
Thanks for the pointer!
I like Claude's use-case and recall Allen citing it too. So, two reasons:
1. Higher-order functional programming wants a function, not literal syntax.
2. Subclassing Array works too, thanks to ES6's class-side inheritance.
/be
Rick Waldron mailto:waldron.r...@gmail.com
March 3, 2014 at 6:09 AM
On Mon, Mar 3, 2014 at 2:47 AM, Claude Pache claude.pa...@gmail.com
mailto:claude.pa...@gmail.com wrote:
Le 3 mars 2014 à 04:22, Mark Volkmann r.mark.volkm...@gmail.com
mailto:r.mark.volkm...@gmail.com a écrit :
What is an example of a use case where one would choose to use
Array.of instead of the literal array syntax?
Back when Dave Herman and I first dreamed up Array.of, I wrote this
up: https://gist.github.com/rwaldron/1074126#arrayof--variable-arity-
Rick
Here is one case where literal array syntax is not possible:
class ImprovedArray extends Array { ... }
let a = ImprovedArray.of( ... )
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org mailto: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
Claude Pache mailto:claude.pa...@gmail.com
March 2, 2014 at 11:47 PM
Here is one case where literal array syntax is not possible:
class ImprovedArray extends Array { ... }
let a = ImprovedArray.of( ... )
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mark Volkmann mailto:r.mark.volkm...@gmail.com
March 2, 2014 at 7:22 PM
What is an example of a use case where one would choose to use
Array.of instead of the literal array syntax?
--
R. Mark Volkmann
Object Computing, Inc.
___
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
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
Generator * syntax
Is the function* syntax for generators final? I'm curious what the justification for it is, but mostly I just need to know if it's likely to change. Thanks, Joe ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator * syntax
On Mon, Mar 3, 2014 at 6:44 PM, joe joe...@gmail.com wrote:
Is the function* syntax for generators final?
Yes
I'm curious what the justification for it is,
The yield keyword was previously only reserved in strict mode (ES5
7.6.1.2), which means it's perfectly valid JS to have: function f() { var
yield = 1; return yield; } in non-strict mode code. In order to allow
generator functions in both strict and non-strict code, where yield is a
keyword, a new syntactic form was needed, ie. the star (generator)
function. This avoids potentially breaking any existing code that is using
yield as an identifier.
but mostly I just need to know if it's likely to change.
I'm confident that it will not change.
Rick
___
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
typed arrays
Are typed arrays considered to be part of ES6? I see they are described in the ES6 working draft, but when I find lists of ES6 features on the web, I never see those included. I see they are also described in a separate specification here: http://www.khronos.org/registry/typedarray/specs/latest/ . -- R. Mark Volkmann Object Computing, Inc. ___ 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 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: typed arrays
On Mar 3, 2014, at 4:50 PM, Mark Volkmann wrote: Are typed arrays considered to be part of ES6? I see they are described in the ES6 working draft, but when I find lists of ES6 features on the web, I never see those included. I see they are also described in a separate specification here: http://www.khronos.org/registry/typedarray/specs/latest/. Yes, they are part of ES6 and the Typed Array specification in the ES6 spec. is intended to supersede the Khronos spec. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptors(O) ? // plural
up ?
On Sun, Mar 2, 2014 at 5:43 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Brandon I take your answer as +1, thanks.
I've also gisted a possible/basic polyfill here:
https://gist.github.com/WebReflection/9317065
Cheers
On Sun, Mar 2, 2014 at 5:16 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
actually, since `Object.getOwnPropertyDescriptor` accepts `Symbols` too
as second argument, the equivalent with current ES6 would be even more
prolix than that
```javascript
var shallowCopy = Object.create(
Object.getPrototypeOf(originalObject),
Object.getOwnPropertyNames(originalObject).concat(
Object.getOwnPropertySymbols(originalObject)
).reduce(function (descriptors, name) {
descriptors[name] = Object.getOwnPropertyDescriptor(
originalObject, name
);
return descriptors;
}, {})
);
```
assuming Symbols will be definable through descriptors ... all this VS
```javascript
var shallowCopy = Object.create(
Object.getPrototypeOf(originalObject),
Object.getOwnPropertyDescriptors(originalObject)
);
```
which I believe is a win.
Thanks
On Sun, Mar 2, 2014 at 5:01 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I wonder if by any chance this could sneak into ES6 ... we have only
singular version here:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.getownpropertydescriptor
**rationale**
The easiest way to create a shallow copy of a generic object could be:
```javascript
var shallowCopy = Object.create(
Object.getPrototypeOf(originalObject),
Object.getOwnPropertyDescriptors(originalObject)
);
```
Today what we have to do this instead:
```javascript
var shallowCopy = Object.create(
Object.getPrototypeOf(originalObject),
Object.getOwnPropertyNames(originalObject).reduce(
function (descriptors, name) {
descriptors[name] = Object.getOwnPropertyDescriptor(
originalObject, name
);
return descriptors;
}, {})
);
```
I see latter pattern as sort of unnecessary overhead that could be also
much faster in core and polyfilled in the meanwhile.
Thoughts ?
Cheers
___
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
