Re: Why can’t for-of be applied to iterators?
Le 13 juin 2013 à 03:33, Brendan Eich bren...@mozilla.com a écrit : Andreas Rossberg wrote: On 12 June 2013 23:27, Claude Pacheclaude.pa...@gmail.com wrote: Therefore, I think that For/of coerces its argument to an iterator is a wrong mental model, and For/of accepts either a reusable iterable or a disposable iterator is a better one. And the implicit invocation of `@@iterator` is better thought as Get-the-snark-I-need-for-doing-my-work, than as Coerce-to-a-disposable-object. (And the fact that iterators are also non-reusable iterables is an implementation detail that don't disturb my mental model, because I don't care, thanks to generators.) In other words, you want to program with iterables. That is a perfectly reasonable thing to want. But unfortunately, with the current intermingled protocol, there is no particularly useful contract of what an iterable actually does (i.e., where the state goes). No, the contract is perfectly useful and minimal. An array is iterable, it has @iterator. Yes, the name of the contract is `@@iterator`. A for/of loop is normally used to loop over an entire collection of items, so it is expected that the user provides an object from which one could extract a fresh (i.e. non-consumed) iterator. In order to enforce that requirement, one could ask iterators to remove or poison-pill its own `@@iterator` method as soon as its `next` method is called. *That* would add extra value (better error-checking) to the programmer, if we find it worth. But replacing `@@iterator` with `ToIterator` is mostly changing an implementation detail. Consequently, if you want to write abstractions, you will likely be better off basing them on iterators, and leave iterables as a mere convenience mechanism for for-of loops over concrete objects. This does not follow. It flies in the face of boatloads of experience with JS and Python (itertools and beyond). I guess we are going 'round the assertion block. I've seen that building before :-|. /be If I want to write an abstraction in a library which loops over an entire collection (e.g,, an `Iter.reduce` function), I just invoke the `@@iterator` method to get an assumed fresh iterator (and it is the responsibility of the user to not provide me with a consumed or half-consumed iterator, unless we add the error-check I mentioned above). If we replace the `@@iterator` method call by an abstract `ToIterator` or `GetIterator` operation, there should be a, say, `Reflect.ToIterator` function that I could use in my library code. ―Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
Bumping this old thread since V8 issue #90 (https://code.google.com/p/v8/issues/detail?id=90) has been getting lots of comments lately. It appears that unstable sort, while perfectly spec-compliant, doesn’t match user expectations. It doesn’t help that some browsers/engines _do_ use a stable sorting algorithm, while others don’t — which surprises people and occasionally breaks (badly-written, but hey) code. (See the thread I linked to for examples.) Then, there’s V8, which uses stable sort for small arrays with 10 or fewer elements, but an unstable sorting algorithm for larger arrays, causing even more confusion. Here’s a test case that tests arrays of varying sizes: http://ofb.net/~sethml/is-sort-stable.html The results in different browsers are listed, too. IMHO it would be nice if ES would require a stable sorting algorithm: it would match user expectations, cause fewer issues in existing code, and improve operability in general. What would be the best way to make TC39 consider this change? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
Even if stable sorts don't get required, it would make sense to require that a given implementation is either always stable or always not stable. The current situation with V8 seems likely to result in subtly broken software shipping to the web, where it works in testing environments with small amounts of data and then breaks in the wild only on certain browsers and only if you have a certain amount of data. Yuck. -kg On Thu, Jun 13, 2013 at 6:05 AM, Mathias Bynens math...@qiwi.be wrote: Bumping this old thread since V8 issue #90 ( https://code.google.com/p/v8/issues/detail?id=90) has been getting lots of comments lately. It appears that unstable sort, while perfectly spec-compliant, doesn’t match user expectations. It doesn’t help that some browsers/engines _do_ use a stable sorting algorithm, while others don’t — which surprises people and occasionally breaks (badly-written, but hey) code. (See the thread I linked to for examples.) Then, there’s V8, which uses stable sort for small arrays with 10 or fewer elements, but an unstable sorting algorithm for larger arrays, causing even more confusion. Here’s a test case that tests arrays of varying sizes: http://ofb.net/~sethml/is-sort-stable.html The results in different browsers are listed, too. IMHO it would be nice if ES would require a stable sorting algorithm: it would match user expectations, cause fewer issues in existing code, and improve operability in general. What would be the best way to make TC39 consider this change? ___ 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: Object.mixin( source, target ) | arguments changed
A real brain-bender for all those extend workalike users. LHS, RHS assignment-expression order is best (Moto 68K vs. Intel 808x asm wars; also gdb vs. binutils IIRC). The lack of extensibility (or should we allow multiple sources now?) is the killer for me. /be Tobias Buschor wrote: I propose to change the arguments. The second argument target is optional and default to Object.create(null) The return-value is the modified target Advantages: - Without the second argument, we can copy the source - It is more natural to say mixin the source into the target = misin.(source, target) Disadvantages - Its not suitable to extend the function to accept multiple sources in the future ___ 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: Array#sort() implementations not interoperable
I don't really care about the precise language or semantics. I just don't want applications to break in the wild because an Array.sort implementation's stability changes based on the number of elements. That feels like a much easier problem to solve than the problem of some browsers being unstable and some being stable. This is absolutely the sort of thing that would bite me as a JS dev and will bite every person who uses my compiler to convert an application. Why would they test with both small and large element counts? -kg On Thu, Jun 13, 2013 at 8:16 AM, Mark S. Miller erig...@google.com wrote: On Thu, Jun 13, 2013 at 7:01 AM, Kevin Gadd kevin.g...@gmail.com wrote: Even if stable sorts don't get required, it would make sense to require that a given implementation is either always stable or always not stable. How would such a requirement differ from the status quo? Doesn't the current v8 impl satisfy it, since a sort that happens to be stable still meets the requirements of an unstable sort? What does always not stable mean? The current situation with V8 seems likely to result in subtly broken software shipping to the web, where it works in testing environments with small amounts of data and then breaks in the wild only on certain browsers and only if you have a certain amount of data. Yuck. -kg On Thu, Jun 13, 2013 at 6:05 AM, Mathias Bynens math...@qiwi.be wrote: Bumping this old thread since V8 issue #90 ( https://code.google.com/p/v8/issues/detail?id=90) has been getting lots of comments lately. It appears that unstable sort, while perfectly spec-compliant, doesn’t match user expectations. It doesn’t help that some browsers/engines _do_ use a stable sorting algorithm, while others don’t — which surprises people and occasionally breaks (badly-written, but hey) code. (See the thread I linked to for examples.) Then, there’s V8, which uses stable sort for small arrays with 10 or fewer elements, but an unstable sorting algorithm for larger arrays, causing even more confusion. Here’s a test case that tests arrays of varying sizes: http://ofb.net/~sethml/is-sort-stable.html The results in different browsers are listed, too. IMHO it would be nice if ES would require a stable sorting algorithm: it would match user expectations, cause fewer issues in existing code, and improve operability in general. What would be the best way to make TC39 consider this change? ___ 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 -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Object.mixin( source, target ) | arguments changed
It seems es-discuss receives a lot of these emails, bikeshedding the behavior of `Object.mixin` from people with preconceived notions of what a mixin is and what a mixin function should do, how it should integrate with class syntax, etc. In contrast, when it was just `Object.define`, it was obscure enough nobody seemed to misinterpret it in such ways. I'm not necessarily suggesting TC39 should switch the name just so that es-discuss stops getting these kind of emails... but maybe it's a sign that mixin is not the best choice. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin( source, target ) | arguments changed
On Thu, Jun 13, 2013 at 12:08 PM, Domenic Denicola dome...@domenicdenicola.com wrote: It seems es-discuss receives a lot of these emails, bikeshedding the behavior of `Object.mixin` from people with preconceived notions of what a mixin is and what a mixin function should do, how it should integrate with class syntax, etc. In contrast, when it was just `Object.define`, it was obscure enough nobody seemed to misinterpret it in such ways. I'm not necessarily suggesting TC39 should switch the name just so that es-discuss stops getting these kind of emails... but maybe it's a sign that mixin is not the best choice. These points are all very valid and I'd be willing to champion a name change for these reasons. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin( source, target ) | arguments changed
On Thu, Jun 13, 2013 at 11:38 AM, Tobias Buschor
tobias.busc...@gmail.comwrote:
I propose to change the arguments.
The second argument target is optional and default to
Object.create(null)
This can already be achieved with Object.mixin(Object.create(null), source)
or if you've imported the dict module (or dict from whatever module it
lives in) Object.mixin(dict(), source)
The return-value is the modified target
This is already true.
Advantages:
- Without the second argument, we can copy the source
This can already be achieved with Object.mixin({}, source).
- It is more natural to say mixin the source into the target =
misin.(source, target)
Subjectively, maybe? None of the existing cow-highways look like this.
Disadvantages
- Its not suitable to extend the function to accept multiple sources in
the future
It also means that Object.assign's arguments would have to be flipped.
Based on this and the example shown above, I think it's fair to say that
reversing the arguments isn't in the ES6's best interest.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin( source, target ) | arguments changed
Based on this and the example shown above, I think it's fair to say that
reversing the arguments isn't in the ES6's best interest.
Definitely. Reversing the argument order would make for awkward code like
this:
Object.mixin({
a() {},
b: 123,
c
}, target);
And I agree that we should attempt to find a different name for mixin, if
possible. (although it means I'll have to change my bleeding edge code yet
again!)
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin( source, target ) | arguments changed
While I like the name mixin, I infinitely like the name define more. Better
still I LOVE this
http://wiki.ecmascript.org/doku.php?id=strawman:define_properties_operator
On Thu, Jun 13, 2013 at 10:09 AM, Kevin Smith zenpars...@gmail.com wrote:
Based on this and the example shown above, I think it's fair to say that
reversing the arguments isn't in the ES6's best interest.
Definitely. Reversing the argument order would make for awkward code like
this:
Object.mixin({
a() {},
b: 123,
c
}, target);
And I agree that we should attempt to find a different name for mixin,
if possible. (although it means I'll have to change my bleeding edge code
yet again!)
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
- Matthew Robb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
I have read the ES specs multiple times, and still accidentally shipped an application that was broken by Array.sort's default behavior in the wild. I know other people who have had the same issues, and people who have read the spec and don't happen to have particular quirks defined in the spec memorized. People are not great at remembering spec details. Simply demanding that all JS developers in the wild read the spec will *not* address these issues. Modern application development occurs on multiple platforms, in multiple languages, using multiple libraries. No matter how many times the spec is read, if the developer is regularly writing and thinking in different languages using different primitives, the primitives that defy trends and act in unexpected ways will always be a stumbling block. The v8 issue and related issue reports against Underscore both serve to demonstrate this. I don't understand why you would intentionally sidetrack a discussion about a simple problem with academic details. Yes, if your goal is to write proofs or rigorously demonstrate that your software is correct all the time, the exact definition of different sort algorithms and terminology really does matter, and yes, it is valuable for people to read the spec. But that is not remotely relevant to the original post in this discussion thread and was not suggested by my replies either. This thread *should* be about whether the ES spec can protect developers from subtle mistakes and errors by changing the specification of Array.sort. Is the point trying to be made here that it is impossible for the spec to clearly communicate that implementations should not do what V8 does, and this communication is impossible because of the academic definition? You haven't even once addressed the original core question of whether it would be possible to switch Array.sort to being stable, and what the obstacles to that would be. There are examples out there in the wild of how difficult it is to write a performant sort in JS from scratch; you need only look at the Bugzilla bug about self-hosting Array.sort in Spidermonkey. Or we can look at the number of *broken* binary search implementations out in the wild caused by people copying from broken algorithms in textbooks that behave incorrectly in boundary cases. Please, for the love of $deity, do not just tell developers to type a query into stackoverflow and grab the top result. I don't necessarily think that it is automatically the right choice to say 'do it yourself' for a problem like this, though it could easily be correct in this specific case, since Underscore ships a stable sort function. Most developers probably use jQuery and/or Underscore already to make up for the small number of useful primitives in the JS standard library, and that's fine. -kg On Thu, Jun 13, 2013 at 9:50 AM, David Bruant bruan...@gmail.com wrote: Le 13/06/2013 17:56, Kevin Gadd a écrit : I don't really care about the precise language or semantics. Maybe you should. In my opinion, that would certainly help having your case better understood and heard. I just don't want applications to break in the wild because an Array.sort implementation's stability changes based on the number of elements. A stable sort is just a particular case of an unstable sort. So, if a sort is sometimes unstable, then it is always unstable. The impression of a stability for some cases is just a distraction. It's also not like if sort was confusing like isNaN. sort does its job. That feels like a much easier problem to solve than the problem of some browsers being unstable and some being stable. This is absolutely the sort of thing that would bite me as a JS dev and will bite every person who uses my compiler to convert an application. Why would they test with both small and large element counts? They can also read the spec and learn they can't rely on sort stability (second sentence of ES5 - 15.4.4.11 !). Specs aren't just for implementors. As a web developer, I feel it's a time-consuming yet very healthy exercise to read specs to avoid pain later down the road. I wouldn't have said that for ES3, but ES5 is decently developer friendly, especially http://es5.github.io/#x15.4.4.**11 http://es5.github.io/#x15.4.4.11with links and all that. If people are unsatisfied with the language sort function, maybe they should pick a different sort function, implement one that fits their need, why not. They can even monkeypatch array#sort! Why not try a stackoverflow sort [1][2]? Try with stable sort ;-) David [1] http://xkcd.com/1185/ [2] http://gkoberger.github.io/**stacksort/http://gkoberger.github.io/stacksort/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
JSC switched to an always stable sort years ago due to compatibility problems with content targeting firefox and IE depending on it. We also had issues with inconsistent comparison functions, but i can't recall exactly what the reasoning behind it was (nor the exact behavior we felt was necessary), but we ended up with an AVL tree being involved, so we may be attempting to only compare two elements with each other once. Unfortunately this code is a little bit gnarly for me to read and understand today :-( I believe that the spec should mandate a stable sort, but i'm not sure just how far we can go in trying to standardize exact behavior of the sort without tying implementations to a single implementation for all time. --Oliver On Jun 13, 2013, at 12:16 PM, Kevin Gadd kevin.g...@gmail.com wrote: I have read the ES specs multiple times, and still accidentally shipped an application that was broken by Array.sort's default behavior in the wild. I know other people who have had the same issues, and people who have read the spec and don't happen to have particular quirks defined in the spec memorized. People are not great at remembering spec details. Simply demanding that all JS developers in the wild read the spec will *not* address these issues. Modern application development occurs on multiple platforms, in multiple languages, using multiple libraries. No matter how many times the spec is read, if the developer is regularly writing and thinking in different languages using different primitives, the primitives that defy trends and act in unexpected ways will always be a stumbling block. The v8 issue and related issue reports against Underscore both serve to demonstrate this. I don't understand why you would intentionally sidetrack a discussion about a simple problem with academic details. Yes, if your goal is to write proofs or rigorously demonstrate that your software is correct all the time, the exact definition of different sort algorithms and terminology really does matter, and yes, it is valuable for people to read the spec. But that is not remotely relevant to the original post in this discussion thread and was not suggested by my replies either. This thread *should* be about whether the ES spec can protect developers from subtle mistakes and errors by changing the specification of Array.sort. Is the point trying to be made here that it is impossible for the spec to clearly communicate that implementations should not do what V8 does, and this communication is impossible because of the academic definition? You haven't even once addressed the original core question of whether it would be possible to switch Array.sort to being stable, and what the obstacles to that would be. There are examples out there in the wild of how difficult it is to write a performant sort in JS from scratch; you need only look at the Bugzilla bug about self-hosting Array.sort in Spidermonkey. Or we can look at the number of *broken* binary search implementations out in the wild caused by people copying from broken algorithms in textbooks that behave incorrectly in boundary cases. Please, for the love of $deity, do not just tell developers to type a query into stackoverflow and grab the top result. I don't necessarily think that it is automatically the right choice to say 'do it yourself' for a problem like this, though it could easily be correct in this specific case, since Underscore ships a stable sort function. Most developers probably use jQuery and/or Underscore already to make up for the small number of useful primitives in the JS standard library, and that's fine. -kg On Thu, Jun 13, 2013 at 9:50 AM, David Bruant bruan...@gmail.com wrote: Le 13/06/2013 17:56, Kevin Gadd a écrit : I don't really care about the precise language or semantics. Maybe you should. In my opinion, that would certainly help having your case better understood and heard. I just don't want applications to break in the wild because an Array.sort implementation's stability changes based on the number of elements. A stable sort is just a particular case of an unstable sort. So, if a sort is sometimes unstable, then it is always unstable. The impression of a stability for some cases is just a distraction. It's also not like if sort was confusing like isNaN. sort does its job. That feels like a much easier problem to solve than the problem of some browsers being unstable and some being stable. This is absolutely the sort of thing that would bite me as a JS dev and will bite every person who uses my compiler to convert an application. Why would they test with both small and large element counts? They can also read the spec and learn they can't rely on sort stability (second sentence of ES5 - 15.4.4.11 !). Specs aren't just for implementors. As a web developer, I feel it's a time-consuming yet very healthy exercise to
Conflicts using export *
Take the following situation:
// M.js
export * from foo;
export * from bar;
// foo
export var x = 1;
// bar
export var x = 2;
What is M.x bound to? foo.x (1), bar.x (2), or is this an error? What is
our current thinking?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
On 6/13/13 at 12:24 PM, oli...@apple.com (Oliver Hunt) wrote: I believe that the spec should mandate a stable sort, but i'm not sure just how far we can go in trying to standardize exact behavior of the sort without tying implementations to a single implementation for all time. One possibility which will allow implementations to include a more performant sort is to specify two sorts: sort - which is stable unstablestort - which is either an alias for sort or is a faster unstable sort. Cheers - Bill --- Bill Frantz|Web security is like medicine - trying to do good for 408-356-8506 |an evolved body of kludges - Mark Miller www.pwpconsult.com | ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Conflicts using export *
This is a static error.
On Thu, Jun 13, 2013 at 3:37 PM, Kevin Smith zenpars...@gmail.com wrote:
Take the following situation:
// M.js
export * from foo;
export * from bar;
// foo
export var x = 1;
// bar
export var x = 2;
What is M.x bound to? foo.x (1), bar.x (2), or is this an error? What is
our current thinking?
{ Kevin }
___
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: Conflicts using export *
M.x is the local variable, because otherwise changes in the exports of
`foo` could, unbenknownst to M, cause an error.
I agree.
Also, I misspoke earlier. The error is only if you *use* M.x, for the
same reason.
Ah - subtle but important point.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin( source, target ) | arguments changed
On Jun 13, 2013, at 10:09 AM, Kevin Smith wrote:
Based on this and the example shown above, I think it's fair to say that
reversing the arguments isn't in the ES6's best interest.
Definitely. Reversing the argument order would make for awkward code like
this:
Object.mixin({
a() {},
b: 123,
c
}, target);
And I agree that we should attempt to find a different name for mixin, if
possible. (although it means I'll have to change my bleeding edge code yet
again!)
We went through this once before and considered other names including define
and extend and concluded that mixin has the fewest warts. I'm not sure how
useful it is to revisit the names again.
I personally don't see that there is any real conflict between Object.mixin and
a hypothetical mixin superclass combinator that someone might define in the
future. They are distinct functions, that do different (but conceptually
somewhat related) things. It's not obvious to me that Object.mixin would be
any more of a source of confusion than define, extend, or any other English
word that might also be used in other contexts.
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
Le 13/06/2013 21:16, Kevin Gadd a écrit :
I have read the ES specs multiple times, and still accidentally
shipped an application that was broken by Array.sort's default
behavior in the wild. I know other people who have had the same
issues, and people who have read the spec and don't happen to have
particular quirks defined in the spec memorized. People are not great
at remembering spec details.
Agreed. The spec on the web. I re-read it the parts I have doubts about
regularly. I write and read doc because spec prose can be tiresome. I
just changed MDN to be very clear on the fact that sorts aren't expected
to be stable. Feel free to contribute to MDN (or WebPlatform at your
preference, both are wikis) whenever you feel that something should be
easily found and shouldn't have to be remembered by developers.
Modern development isn't a person against a programming language. The
web is part of modern development.
Simply demanding that all JS developers in the wild read the spec will
*not* address these issues. Modern application development occurs on
multiple platforms, in multiple languages, using multiple libraries.
No matter how many times the spec is read, if the developer is
regularly writing and thinking in different languages using different
primitives, the primitives that defy trends and act in unexpected ways
will always be a stumbling block. The v8 issue and related issue
reports against Underscore both serve to demonstrate this.
I don't understand why you would intentionally sidetrack a discussion
about a simple problem with academic details. Yes, if your goal is to
write proofs or rigorously demonstrate that your software is correct
all the time, the exact definition of different sort algorithms and
terminology really does matter
I only cared about the words stable and unstable which are at the
heart of the debate. I'm not sure I understand what academic details
you're referring to and why you're talking about proofs.
A sort being stable is a property on the position of elements which are
considered equal by the sort algorithm. If people want equal elements to
not be moved, they should let the comparator believe that they are equal.
This is not about academics or proof. It's about understanding what
you're doing. Properly understanding the tools at your disposals, the
abstractions. In essence, it's asking the very skills that are required
to build any sort of software.
and yes, it is valuable for people to read the spec. But that is not
remotely relevant to the original post in this discussion thread and
was not suggested by my replies either. This thread *should* be about
whether the ES spec can protect developers from subtle mistakes and
errors by changing the specification of Array.sort. Is the point
trying to be made here that it is impossible for the spec to clearly
communicate that implementations should not do what V8 does, and this
communication is impossible because of the academic definition? You
haven't even once addressed the original core question of whether it
would be possible to switch Array.sort to being stable, and what the
obstacles to that would be.
My (implicit, sorry about that) point was that there is no need to
change the sort function. Just for people to read the spec or doc. No
one is a hero and expected to remember everything, but reading the
second sentence of the Array.prototype.sort spec seems rather low-cost
to me.
There are examples out there in the wild of how difficult it is to
write a performant sort in JS from scratch; you need only look at the
Bugzilla bug about self-hosting Array.sort in Spidermonkey. Or we can
look at the number of *broken* binary search implementations out in
the wild caused by people copying from broken algorithms in textbooks
that behave incorrectly in boundary cases. Please, for the love of
$deity, do not just tell developers to type a query into stackoverflow
and grab the top result.
That was a joke obviously :-) But open source, robust, well-tested
algorithms exist.
Alternate proposal to forcing stable sorts in the spec based on the idea
that equal elements shouldn't be equal:
Have the original index of a value passed to the comparator function. A
stable sort can then be a few characters away:
arr.sort(compare)
becomes:
arr.sort((v1, v2, i1, i2) = { return compare(v1, v2) || i1 i2; })
Where the compare function considers v1 and v2 to be equal (returns 0,
only falsy number), original indices are used to decide which is
greater. This should stabilize the output I think (by fully ordering
elements either by their value when one is greater than the other and by
original index when the 2 values are considered equal by the compare
function)
A simple and optimistic static analysis (no arguments, no eval, 3rd
and 4th arg undeclared, etc.) on the comparator body should leave perf
roughly intact.
David
___
Re: Object.mixin( source, target ) | arguments changed
Allen Wirfs-Brock wrote: I personally don't see that there is any real conflict between Object.mixin and a hypothetical mixin superclass combinator that someone might define in the future. What about multiple sources? That might take almost all the perceived conflict away. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
Just confirming: In ES1 days, the MS guy (Shon K.) suggested stability but we all agreed not to require it, but I believe he implemented it. This created a de-facto standard and SpiderMonkey and JSC matched. I think V8 has a de-facto bug to fix. I'm ok with requiring stability as a normative property of Array.prototype.sort given such a V8 bugfix. I don't yet see enough value in adding an unstableSort (to Bill F's point). /be Oliver Hunt wrote: JSC switched to an always stable sort years ago due to compatibility problems with content targeting firefox and IE depending on it. We also had issues with inconsistent comparison functions, but i can't recall exactly what the reasoning behind it was (nor the exact behavior we felt was necessary), but we ended up with an AVL tree being involved, so we may be attempting to only compare two elements with each other once. Unfortunately this code is a little bit gnarly for me to read and understand today :-( I believe that the spec should mandate a stable sort, but i'm not sure just how far we can go in trying to standardize exact behavior of the sort without tying implementations to a single implementation for all time. --Oliver On Jun 13, 2013, at 12:16 PM, Kevin Gadd kevin.g...@gmail.com mailto:kevin.g...@gmail.com wrote: I have read the ES specs multiple times, and still accidentally shipped an application that was broken by Array.sort's default behavior in the wild. I know other people who have had the same issues, and people who have read the spec and don't happen to have particular quirks defined in the spec memorized. People are not great at remembering spec details. Simply demanding that all JS developers in the wild read the spec will *not* address these issues. Modern application development occurs on multiple platforms, in multiple languages, using multiple libraries. No matter how many times the spec is read, if the developer is regularly writing and thinking in different languages using different primitives, the primitives that defy trends and act in unexpected ways will always be a stumbling block. The v8 issue and related issue reports against Underscore both serve to demonstrate this. I don't understand why you would intentionally sidetrack a discussion about a simple problem with academic details. Yes, if your goal is to write proofs or rigorously demonstrate that your software is correct all the time, the exact definition of different sort algorithms and terminology really does matter, and yes, it is valuable for people to read the spec. But that is not remotely relevant to the original post in this discussion thread and was not suggested by my replies either. This thread *should* be about whether the ES spec can protect developers from subtle mistakes and errors by changing the specification of Array.sort. Is the point trying to be made here that it is impossible for the spec to clearly communicate that implementations should not do what V8 does, and this communication is impossible because of the academic definition? You haven't even once addressed the original core question of whether it would be possible to switch Array.sort to being stable, and what the obstacles to that would be. There are examples out there in the wild of how difficult it is to write a performant sort in JS from scratch; you need only look at the Bugzilla bug about self-hosting Array.sort in Spidermonkey. Or we can look at the number of *broken* binary search implementations out in the wild caused by people copying from broken algorithms in textbooks that behave incorrectly in boundary cases. Please, for the love of $deity, do not just tell developers to type a query into stackoverflow and grab the top result. I don't necessarily think that it is automatically the right choice to say 'do it yourself' for a problem like this, though it could easily be correct in this specific case, since Underscore ships a stable sort function. Most developers probably use jQuery and/or Underscore already to make up for the small number of useful primitives in the JS standard library, and that's fine. -kg On Thu, Jun 13, 2013 at 9:50 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 13/06/2013 17:56, Kevin Gadd a écrit : I don't really care about the precise language or semantics. Maybe you should. In my opinion, that would certainly help having your case better understood and heard. I just don't want applications to break in the wild because an Array.sort implementation's stability changes based on the number of elements. A stable sort is just a particular case of an unstable sort. So, if a sort is sometimes unstable, then it is always unstable. The impression of a stability for some cases is just a distraction. It's also not like if sort was confusing like isNaN. sort does its job. That feels like a much easier
Re: Conflicts using export *
Kevin Smith wrote: Also, I misspoke earlier. The error is only if you *use* M.x, for the same reason. Ah - subtle but important point. Yes, super-important in a growing independently-owned modules setting. I.e., reality. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin( source, target ) | arguments changed
On Thu, Jun 13, 2013 at 5:38 PM, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: I personally don't see that there is any real conflict between Object.mixin and a hypothetical mixin superclass combinator that someone might define in the future. What about multiple sources? That might take almost all the perceived conflict away. This would also apply to Object.assign Rick /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
On Thu, Jun 13, 2013 at 12:16 PM, Kevin Gadd kevin.g...@gmail.com wrote: I don't understand why you would intentionally sidetrack a discussion about a simple problem with academic details. He brings up a very real point, which is that you can't realistically have an always unstable sort. If I understand you correctly, what you want by an always unstable sort is that you want developers to get bitten in testing due to instability, even for small test cases, so that the issue is caught earlier. The problem with that desire is that there are no sorting algorithms AFAIK that guarantee that they will *always* rearrange equal-sorting elements (i.e., always unstable): even a pure recursive quicksort (no insertion-sort base case) will sometimes not rearrange equal-sorting elements (i.e., seem stable). If I understand your desire correctly, then what you're asking for by always unstable is to require that if an implementation's sorting algorithm *might* rearrange equal-sorting elements, then it must *always* go out of its way to ensure that if equal-sorting elements are present, then it does not preserve their order; I haven't looked in detail at what this would mean from an implementation standpoint, but I'm pretty sure that it is unrealistic. -- Sean Silva ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
Always-unstable is trivial: use a stable sort, and the first time you encounter two elements that compare equal, swap them. The problem with that is it isn't necessarily detectably unstable. The two elements you swap might be equal in all ways. To be detectably unstable, you need the sort function to know when two elements that compare equal are not otherwise equal, so you have to pass it a second comparison function, and if you can do that why are you bothering with an unstable sort in the first place? I think I'm confused about the point of always unstable. An alternate interpretation of always unstable is for sort to throw an error anytime it encounters two elements that compare equal. Which is pretty annoyingly useless. You might as well just use a stable sort all the time. On Thu, Jun 13, 2013 at 3:10 PM, Sean Silva sil...@purdue.edu wrote: On Thu, Jun 13, 2013 at 12:16 PM, Kevin Gadd kevin.g...@gmail.com wrote: I don't understand why you would intentionally sidetrack a discussion about a simple problem with academic details. He brings up a very real point, which is that you can't realistically have an always unstable sort. If I understand you correctly, what you want by an always unstable sort is that you want developers to get bitten in testing due to instability, even for small test cases, so that the issue is caught earlier. The problem with that desire is that there are no sorting algorithms AFAIK that guarantee that they will *always* rearrange equal-sorting elements (i.e., always unstable): even a pure recursive quicksort (no insertion-sort base case) will sometimes not rearrange equal-sorting elements (i.e., seem stable). If I understand your desire correctly, then what you're asking for by always unstable is to require that if an implementation's sorting algorithm *might* rearrange equal-sorting elements, then it must *always* go out of its way to ensure that if equal-sorting elements are present, then it does not preserve their order; I haven't looked in detail at what this would mean from an implementation standpoint, but I'm pretty sure that it is unrealistic. -- Sean Silva ___ 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: Object.mixin( source, target ) | arguments changed
On Thu, Jun 13, 2013 at 2:38 PM, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: I personally don't see that there is any real conflict between Object.mixin and a hypothetical mixin superclass combinator that someone might define in the future. What about multiple sources? That might take almost all the perceived conflict away. The question which help to solve is: Why _not_ to have multiple sources? If there are strong concerns, then one source is the way, otherwise multiple sources seems more functional. Dmitry ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.mixin( source, target ) | arguments changed
Rick talked about a third argument but if that won't exist I like multiple sources too. It's also more suitable as Object.mixin(target, ...[source1, source2, source3]) for predefined collections of mixins to reuse +1 here On Thu, Jun 13, 2013 at 3:57 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: On Thu, Jun 13, 2013 at 2:38 PM, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: I personally don't see that there is any real conflict between Object.mixin and a hypothetical mixin superclass combinator that someone might define in the future. What about multiple sources? That might take almost all the perceived conflict away. The question which help to solve is: Why _not_ to have multiple sources? If there are strong concerns, then one source is the way, otherwise multiple sources seems more functional. Dmitry ___ 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: Object.mixin( source, target ) | arguments changed
If one thinks about how Andrea Giammarchi might have come up
with his already reliable implementation of [Object.mixin] ...
[https://github.com/WebReflection/object-mixin/blob/master/src/object-mixin.js]
... the need for changing the order of arguments most probably
will become less desirable.
It combines both approaches that today's developers rely on
if they try to extend or augment objects. If it was just
for the many implementations of [*.extend] that do stepwise
copy properties from one object to another it wasn't even worth
discussing it. The second approach mostly gets referred to as
functional or function based mixins - and Andrea's implementation
of [Object.mixin] ...
function (
target, // object to enrich with
source, // mixin object or Trait (Function)
args// optional arguments for Trait
) { ... }
... considers the different variants of this composition
pattern by providing/allowing a third parameter for what
I'm willing to call a Privileged Trait or a Privileged Mixin.
var
PrivilegedTrait = function (injectedReadOnlyState) {
// implementation
},
obj = {
// description
}
;
PrivilegedTrait.call(obj, {state:readonly});
//source.apply(target, args);
Looking at the last line of the given example above there
was really no other solution than Andrea came up with in
order to support in a future proof way what already exists
today in various ways - though neither amount nor precedence
of this methods arguments should be changed.
Secondly. What are the advantages of invoking [Object.mixin]
with more than one source over the disadvantage of loosing
this methods clean interface if there is [Array.forEach] ...
[source_A, source_B, source_C].forEach(function (source) {
Object.mixin(target, source);
});
Thirdly. Andrea's approach easily can be shimmed for ES3
and does not hide JavaScript's natural/native predisposition
for Trait/Mixin composition under to much syntactic sugar.
Last. Only if there should ever the naming of mixin
seriously be questioned again I would propose to choose
[Object.compose] as an alternative.
additional links that might proof what I just brought into discussion:
[http://www.mail-archive.com/es-discuss@mozilla.org/msg22677.html]
[https://github.com/petsel/javascript-code-reuse-patterns]
[https://github.com/petsel/javascript-code-reuse-patterns/blob/master/source/components/composition/Traits/PrivilegedTrait.js]
[https://github.com/petsel/javascript-code-reuse-patterns/blob/master/source/components/composition/Mixins/PrivilegedMixin.js]
thanks - Peter
On Thu, Jun 13, 2013 at 5:38 PM, Tobias Buschor
tobias.busc...@gmail.com wrote:
I propose to change the arguments.
The second argument target is optional and default to Object.create(null)
The return-value is the modified target
Advantages:
- Without the second argument, we can copy the source
- It is more natural to say mixin the source into the target =
misin.(source, target)
Disadvantages
- Its not suitable to extend the function to accept multiple sources in the
future
___
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: Object.mixin( source, target ) | arguments changed
oh dear ... I forgot I wrote that Trait proof already ... well ... I am
willing to change/improve/modify that script if necessary, just let me know
what's the final decision (yep, that was an early shim out of emtpy specs
:D)
thanks for pointing that out
On Thu, Jun 13, 2013 at 4:18 PM, Peter Seliger peter.seli...@googlemail.com
wrote:
If one thinks about how Andrea Giammarchi might have come up
with his already reliable implementation of [Object.mixin] ...
[
https://github.com/WebReflection/object-mixin/blob/master/src/object-mixin.js
]
... the need for changing the order of arguments most probably
will become less desirable.
It combines both approaches that today's developers rely on
if they try to extend or augment objects. If it was just
for the many implementations of [*.extend] that do stepwise
copy properties from one object to another it wasn't even worth
discussing it. The second approach mostly gets referred to as
functional or function based mixins - and Andrea's implementation
of [Object.mixin] ...
function (
target, // object to enrich with
source, // mixin object or Trait (Function)
args// optional arguments for Trait
) { ... }
... considers the different variants of this composition
pattern by providing/allowing a third parameter for what
I'm willing to call a Privileged Trait or a Privileged Mixin.
var
PrivilegedTrait = function (injectedReadOnlyState) {
// implementation
},
obj = {
// description
}
;
PrivilegedTrait.call(obj, {state:readonly});
//source.apply(target, args);
Looking at the last line of the given example above there
was really no other solution than Andrea came up with in
order to support in a future proof way what already exists
today in various ways - though neither amount nor precedence
of this methods arguments should be changed.
Secondly. What are the advantages of invoking [Object.mixin]
with more than one source over the disadvantage of loosing
this methods clean interface if there is [Array.forEach] ...
[source_A, source_B, source_C].forEach(function (source) {
Object.mixin(target, source);
});
Thirdly. Andrea's approach easily can be shimmed for ES3
and does not hide JavaScript's natural/native predisposition
for Trait/Mixin composition under to much syntactic sugar.
Last. Only if there should ever the naming of mixin
seriously be questioned again I would propose to choose
[Object.compose] as an alternative.
additional links that might proof what I just brought into discussion:
[http://www.mail-archive.com/es-discuss@mozilla.org/msg22677.html]
[https://github.com/petsel/javascript-code-reuse-patterns]
[
https://github.com/petsel/javascript-code-reuse-patterns/blob/master/source/components/composition/Traits/PrivilegedTrait.js
]
[
https://github.com/petsel/javascript-code-reuse-patterns/blob/master/source/components/composition/Mixins/PrivilegedMixin.js
]
thanks - Peter
On Thu, Jun 13, 2013 at 5:38 PM, Tobias Buschor
tobias.busc...@gmail.com wrote:
I propose to change the arguments.
The second argument target is optional and default to
Object.create(null)
The return-value is the modified target
Advantages:
- Without the second argument, we can copy the source
- It is more natural to say mixin the source into the target =
misin.(source, target)
Disadvantages
- Its not suitable to extend the function to accept multiple sources in
the future
___
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: Array#sort() implementations not interoperable
On 6/13/13 at 3:53 PM, feli...@gmail.com (felix) wrote: Always-unstable is trivial... Not really. Doing it with a test case that has only one record is hard. It is also hard if the test case has all different records (according to the sort field(s). BTW _ I think having only one sort which is stable is a good solution if performance of sort is not a burning concern. Cheers - Bill --- Bill Frantz| Re: Computer reliability, performance, and security: 408-356-8506 | The guy who *is* wearing a parachute is *not* the www.pwpconsult.com | first to reach the ground. - Terence Kelly ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
I'll state it again since I guess maybe the third time is the charm: When I said 'always stable' or 'always unstable' i was referring to which implementation the browser uses, not what the sort actually does. There's nothing beneficial about the fact that an unstable sort happens to rearrange elements. My point is that explicitly forbidding Array.sort from conditionally switching between sort implementations (or at least from switching between implementations with observable differences) is beneficial to users. Let's not be ridiculous here. -kg On Thu, Jun 13, 2013 at 3:53 PM, felix feli...@gmail.com wrote: Always-unstable is trivial: use a stable sort, and the first time you encounter two elements that compare equal, swap them. The problem with that is it isn't necessarily detectably unstable. The two elements you swap might be equal in all ways. To be detectably unstable, you need the sort function to know when two elements that compare equal are not otherwise equal, so you have to pass it a second comparison function, and if you can do that why are you bothering with an unstable sort in the first place? I think I'm confused about the point of always unstable. An alternate interpretation of always unstable is for sort to throw an error anytime it encounters two elements that compare equal. Which is pretty annoyingly useless. You might as well just use a stable sort all the time. On Thu, Jun 13, 2013 at 3:10 PM, Sean Silva sil...@purdue.edu wrote: On Thu, Jun 13, 2013 at 12:16 PM, Kevin Gadd kevin.g...@gmail.com wrote: I don't understand why you would intentionally sidetrack a discussion about a simple problem with academic details. He brings up a very real point, which is that you can't realistically have an always unstable sort. If I understand you correctly, what you want by an always unstable sort is that you want developers to get bitten in testing due to instability, even for small test cases, so that the issue is caught earlier. The problem with that desire is that there are no sorting algorithms AFAIK that guarantee that they will *always* rearrange equal-sorting elements (i.e., always unstable): even a pure recursive quicksort (no insertion-sort base case) will sometimes not rearrange equal-sorting elements (i.e., seem stable). If I understand your desire correctly, then what you're asking for by always unstable is to require that if an implementation's sorting algorithm *might* rearrange equal-sorting elements, then it must *always* go out of its way to ensure that if equal-sorting elements are present, then it does not preserve their order; I haven't looked in detail at what this would mean from an implementation standpoint, but I'm pretty sure that it is unrealistic. -- Sean Silva ___ 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: Array#sort() implementations not interoperable
On Thu, Jun 13, 2013 at 4:42 PM, Kevin Gadd kevin.g...@gmail.com wrote:
I'll state it again since I guess maybe the third time is the charm:
When I said 'always stable' or 'always unstable' i was referring to which
implementation the browser uses, not what the sort actually does. There's
nothing beneficial about the fact that an unstable sort happens to
rearrange elements. My point is that explicitly forbidding Array.sort from
conditionally switching between sort implementations (or at least from
switching between implementations with observable differences) is
beneficial to users. Let's not be ridiculous here.
Switching to other insertion sort for small input sizes is a key part of
getting high performance out of quicksort. The insertion sort is used as
the base case of the recursion, and I wouldn't really consider it
switching between sort implementations. There is no check like the
following:
Array.prototype.sort = function (cmp) {
if (this.length 20) {
doInsertionSort(this);
} else {
doQuicksort(this);
}
};
It's more like:
Array.prototype.sort = function (cmp) {
quicksortRec(this, 0, this.length, cmp);
};
function quicksortRec(arr, begin, end, cmp) {
if (end - begin 20) {
fastBaseCase(arr, begin, end, cmp); // what this does happens to be
stable
return;
}
// ... slow recursive case
}
-- Sean Silva
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
Looking at the discussion on https://code.google.com/p/v8/issues/detail?id=90 it seems the V8 team is waiting for TC39 to tell them that they have to switch to a stable algorithm. An agenda item for the next meeting? Norbert On Jun 13, 2013, at 14:40 , Brendan Eich wrote: Just confirming: In ES1 days, the MS guy (Shon K.) suggested stability but we all agreed not to require it, but I believe he implemented it. This created a de-facto standard and SpiderMonkey and JSC matched. I think V8 has a de-facto bug to fix. I'm ok with requiring stability as a normative property of Array.prototype.sort given such a V8 bugfix. I don't yet see enough value in adding an unstableSort (to Bill F's point). /be Oliver Hunt wrote: JSC switched to an always stable sort years ago due to compatibility problems with content targeting firefox and IE depending on it. We also had issues with inconsistent comparison functions, but i can't recall exactly what the reasoning behind it was (nor the exact behavior we felt was necessary), but we ended up with an AVL tree being involved, so we may be attempting to only compare two elements with each other once. Unfortunately this code is a little bit gnarly for me to read and understand today :-( I believe that the spec should mandate a stable sort, but i'm not sure just how far we can go in trying to standardize exact behavior of the sort without tying implementations to a single implementation for all time. --Oliver On Jun 13, 2013, at 12:16 PM, Kevin Gadd kevin.g...@gmail.com mailto:kevin.g...@gmail.com wrote: I have read the ES specs multiple times, and still accidentally shipped an application that was broken by Array.sort's default behavior in the wild. I know other people who have had the same issues, and people who have read the spec and don't happen to have particular quirks defined in the spec memorized. People are not great at remembering spec details. Simply demanding that all JS developers in the wild read the spec will *not* address these issues. Modern application development occurs on multiple platforms, in multiple languages, using multiple libraries. No matter how many times the spec is read, if the developer is regularly writing and thinking in different languages using different primitives, the primitives that defy trends and act in unexpected ways will always be a stumbling block. The v8 issue and related issue reports against Underscore both serve to demonstrate this. I don't understand why you would intentionally sidetrack a discussion about a simple problem with academic details. Yes, if your goal is to write proofs or rigorously demonstrate that your software is correct all the time, the exact definition of different sort algorithms and terminology really does matter, and yes, it is valuable for people to read the spec. But that is not remotely relevant to the original post in this discussion thread and was not suggested by my replies either. This thread *should* be about whether the ES spec can protect developers from subtle mistakes and errors by changing the specification of Array.sort. Is the point trying to be made here that it is impossible for the spec to clearly communicate that implementations should not do what V8 does, and this communication is impossible because of the academic definition? You haven't even once addressed the original core question of whether it would be possible to switch Array.sort to being stable, and what the obstacles to that would be. There are examples out there in the wild of how difficult it is to write a performant sort in JS from scratch; you need only look at the Bugzilla bug about self-hosting Array.sort in Spidermonkey. Or we can look at the number of *broken* binary search implementations out in the wild caused by people copying from broken algorithms in textbooks that behave incorrectly in boundary cases. Please, for the love of $deity, do not just tell developers to type a query into stackoverflow and grab the top result. I don't necessarily think that it is automatically the right choice to say 'do it yourself' for a problem like this, though it could easily be correct in this specific case, since Underscore ships a stable sort function. Most developers probably use jQuery and/or Underscore already to make up for the small number of useful primitives in the JS standard library, and that's fine. -kg On Thu, Jun 13, 2013 at 9:50 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 13/06/2013 17:56, Kevin Gadd a écrit : I don't really care about the precise language or semantics. Maybe you should. In my opinion, that would certainly help having your case better understood and heard. I just don't want applications to break in the wild because an Array.sort implementation's stability changes based on the
Intentional breaking change in ES6 draft spec?
The ES6 draft grammar no longer allows the following, which was legal ES5:
for(var i = 1 in []) {}
Was that an intentional breaking change? If so, why? (Of course, there are
exceedingly limited practical uses of this, but that alone doesn't seem to
justify a breaking change).
Luke
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Intentional breaking change in ES6 draft spec?
Luke Hoban wrote:
The ES6 draft grammar no longer allows the following, which was legal ES5:
for(var i = 1 in []) {}
Was that an intentional breaking change? If so, why?
Yes, to simplify and tighten up grammar (and engines). We reckoned that
only testsuites counted on this. This was recorded in some meeting notes
but I'm not free to dig them up right now.
(Of course, there are exceedingly limited practical uses of this, but that
alone doesn't seem to justify a breaking change).
We had some web crawling help, IIRC. We also figured we had time to test
and put it back, if needed. Did you find web content using it?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Intentional breaking change in ES6 draft spec?
This was from back in the days when Google code search was still available
and the only hits we found were from test suites.
On Jun 13, 2013 8:54 PM, Brendan Eich bren...@mozilla.com wrote:
Luke Hoban wrote:
The ES6 draft grammar no longer allows the following, which was legal ES5:
for(var i = 1 in []) {}
Was that an intentional breaking change? If so, why?
Yes, to simplify and tighten up grammar (and engines). We reckoned that
only testsuites counted on this. This was recorded in some meeting notes
but I'm not free to dig them up right now.
(Of course, there are exceedingly limited practical uses of this, but
that alone doesn't seem to justify a breaking change).
We had some web crawling help, IIRC. We also figured we had time to test
and put it back, if needed. Did you find web content using it?
/be
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Intentional breaking change in ES6 draft spec?
From: Erik Arvidsson [mailto:erik.arvids...@gmail.com] This was from back in the days when Google code search was still available and the only hits we found were from test suites. On Jun 13, 2013 8:54 PM, Brendan Eich bren...@mozilla.com wrote: We had some web crawling help, IIRC. We also figured we had time to test and put it back, if needed. Did you find web content using it? We haven't done a run yet to look for content using this. Promising to hear that Google code search didn't hit anything. I'll see if we can get some data here. Was that an intentional breaking change? If so, why? Yes, to simplify and tighten up grammar (and engines). We reckoned that only testsuites counted on this. This was recorded in some meeting notes but I'm not free to dig them up right now. Must have missed that discussion. Doesn't seem a big win for engines or the grammar, as it reduces orthogonality in the grammar wrt variable declarations (I believe this introduces the only place that var x is allowed but cannot have an initializer?). Luke ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Intentional breaking change in ES6 draft spec?
On Jun 13, 2013, at 7:24 PM, Luke Hoban lu...@microsoft.com wrote: From: Erik Arvidsson [mailto:erik.arvids...@gmail.com] This was from back in the days when Google code search was still available and the only hits we found were from test suites. On Jun 13, 2013 8:54 PM, Brendan Eich bren...@mozilla.com wrote: We had some web crawling help, IIRC. We also figured we had time to test and put it back, if needed. Did you find web content using it? We haven't done a run yet to look for content using this. Promising to hear that Google code search didn't hit anything. I'll see if we can get some data here. Thanks. Was that an intentional breaking change? If so, why? Yes, to simplify and tighten up grammar (and engines). We reckoned that only testsuites counted on this. This was recorded in some meeting notes but I'm not free to dig them up right now. Must have missed that discussion. Doesn't seem a big win for engines or the grammar, as it reduces orthogonality in the grammar wrt variable declarations (I believe this introduces the only place that var x is allowed but cannot have an initializer?). Sure, but note the screwy one-declarator-only restriction. The semantics are too string out too in the existing specs prior to ES6. Inlining is better on both syntactic and semantic grounds. /be Luke ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
