2010/5/21 Allen Wirfs-Brock <[email protected]>: >> -----Original Message----- >> From: [email protected] [mailto:es-discuss- >> [email protected]] On Behalf Of Mike Samuel > ... >> David Herman argued that overspecification is a problem in some parts of the >> spec and cited Array.prototype.sort. >> In building your semantics, were there parts of the spec that stood out as >> under- >> specified that could benefit from being described via \JS or desugar? >> > > Did you really mean "overspecification" in the first sentence? > Array.prototype.sort is actually one of the most loosely specified built-in > methods. For example, it doesn't say anything about requiring a specific > sort algorithm and leaves many possible cases as "implementation-defined". > Whether or not this is an appropriate level of specification for this > function is a separate discussion.
I did mean "overspecification." David Herman (CCed) said in https://mail.mozilla.org/pipermail/es-discuss/2010-May/011236.html For example, I don't think the spec should ever provide an executable presentation of |Array.prototype.sort|, for example. and I tend to agree. He may not agree with my reasons. I think that the spec should (1) obviously specify for sort that given a valid comparator, that the array is sorted afterwards (2) try to bound the badness that can happen in corner cases, e.g. around bad comparators (3) specify other properties like stability that are of major concern to users But inevitably some APIs, and the design choices around them are better understood than others. And in the first version of a spec to specify an API, we should provide leeway to implementors to experiment with tradeoffs. The spec shouldn't require exact conformance for all corner cases across the board until the tradeoffs have been properly weighed. Specifically it shouldn't prematurely nail down exactly what should happen if a misbehaving comparator decides to modify the array mid-sort. Doing so prematurely would not leave enough leeway for implementors to experiment with ways to make sort behave as efficiently as possible for the typical case. > Allen > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
