Andreas Rossberg wrote:
On 13 June 2013 23:40, Brendan Eichbren...@mozilla.com wrote:
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.
IIUC, current IE versions are not been stable either, so
Le 14/06/2013 02:37, Mark S. Miller a écrit :
Other things being equal, or even close, I am always in favor of specs
being more deterministic.
Even with this pinned down, we should still allow implementations to
switch among different algorithms based on the size of the array, the
cache
Le 14/06/2013 09:55, Andreas Rossberg a écrit :
On 14 June 2013 09:50, David Bruant bruan...@gmail.com wrote:
And this particular behavior might be standardizable without a loss (even
with a gain), because:
1) a sort algorithm only needs all the array values once at least once
(serie of
On Fri, Jun 14, 2013 at 4:30 AM, Andreas Rossberg rossb...@google.com wrote:
On 14 June 2013 10:17, David Bruant bruan...@gmail.com wrote:
I'm suggesting to make the [[Get]], [[Put]] and [[Delete]] sequence less
implementation-dependent which means at least to bound them to the maximum
of what
On Fri, Jun 14, 2013 at 9:43 AM, Andreas Rossberg rossb...@google.com wrote:
On 14 June 2013 14:11, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Jun 14, 2013 at 4:30 AM, Andreas Rossberg rossb...@google.com
wrote:
I don't see much of a use case for an array with getters, let alone
Andreas Rossberg wrote:
On 13 June 2013 23:40, Brendan Eichbren...@mozilla.com wrote:
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.
IIUC, current IE versions are not been stable either, so calling
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
Hello everyone,
Reposting, I think my previous attempt got stuck in a filter or something,
because I somehow managed to have the code there in several copies.
I was thinking about sorting algorithms yesterday and I realized that ES
implementations may have different sorting algorithms in use,
Jussi Kalliokoski wrote:
Hello everyone,
Reposting, I think my previous attempt got stuck in a filter or
something, because I somehow managed to have the code there in several
copies.
You have three messages total on this topic at
On Mon, Dec 3, 2012 at 8:46 PM, Brendan Eich bren...@mozilla.org wrote:
You have three messages total on this topic at
https://mail.mozilla.org/**pipermail/es-discuss/2012-**December/https://mail.mozilla.org/pipermail/es-discuss/2012-December/
Oh, sorry about the noise, I should've checked
It's abort stability, and I think it's better to keep it un-stable for
performance performance.
On Mon, Dec 3, 2012 at 10:46 PM, Brendan Eich bren...@mozilla.org wrote:
Jussi Kalliokoski wrote:
Hello everyone,
Reposting, I think my previous attempt got stuck in a filter or
something,
I haven't looked into sort algorithms in a while - how much slower are the
fastest stable ones than the fastest non-stable ones?
I ran into the stability issue recently when implementing a function to
interpret HTTP Accept-Language headers [1]. The language tags in these headers
can have
25 matches
Mail list logo
