ES3.1 Draft: 22 Sep 2008 "Redmond" version available
What parts should I look at? The decimal stuff in the document is inconsistent and looks like it's not ready for review yet.
Waldemar
On Tue, Sep 23, 2008 at 4:09 PM, Waldemar Horwat <waldemar at google.com> wrote:
What parts should I look at? The decimal stuff in the document is inconsistent and looks like it's not ready for review yet.
The decimal stuff undoubtedly has bugs, but please do review the version that Pratap sent out.
One minor request: statements like "breaks arrays" are less helpful than specific ECMAScript statements which would fail; better yet would be citing specific deployed code that would fail.
- Sam Ruby
Sam Ruby wrote:
On Tue, Sep 23, 2008 at 4:09 PM, Waldemar Horwat <waldemar at google.com> wrote:
What parts should I look at? The decimal stuff in the document is inconsistent and looks like it's not ready for review yet.
The decimal stuff undoubtedly has bugs, but please do review the version that Pratap sent out.
I'll try but probably won't get far given that the draft was published yesterday, the meeting is tomorrow and I have other things I need to get done in the meantime. The problems in decimal are serious enough that I can't even figure out the intent of the proposal at this point.
One minor request: statements like "breaks arrays" are less helpful than specific ECMAScript statements which would fail; better yet would be citing specific deployed code that would fail.
I already gave specific examples of this and we've had extensive discussions of them. I don't like beating a dead horse any more than necessary.
Waldemar
On Sep 23, 2008, at 1:45 PM, Waldemar Horwat wrote:
Sam Ruby wrote:
One minor request: statements like "breaks arrays" are less helpful than specific ECMAScript statements which would fail; better yet
would be citing specific deployed code that would fail.I already gave specific examples of this and we've had extensive
discussions of them. I don't like beating a dead horse any more
than necessary.
The horse must not be dead. The question is: should a === b imply o
[a] and o[b] refer to the same property, for any object o (modulo the
spec bug that David Jones pointed out whereby 5e-324 could be
converted to strings such as "3e-324" and "7e-324").
Sam seems to think a === b should not imply o[a] and o[b] refer to
the same property (double-cited text is from Jason Orendorff):
Well, the intuition is that two equal numbers should index the same property. This is an invariant in ES3 and it makes a lot of sense.
Correct me if I'm wrong, but the intuition would more properly be
based on string equality, and not numeric equality. As an example, how many properties would the following produce, with an conformant implementation of ES3?var a = []; a['0.0'] = "first"; a[0.0] = "second"; // a second property a['0'] = "third"; // replaces second property
The intuition depends on string equality and ToString in addition to
numeric equality. But it turns out that a === b for any numbers a and
b implies ToString(a) === ToString(b) (except, again, for the very
small numbers David Jones pointed out).
But Sam's decimal implementation has 1.1m === 1.10m.
So the precise issue with "breaks arrays" is the proposal from Sam
and Mike that ToString on a decimal preserve scale digits (I hope I'm
using the right term). That breaks the a === b => o[a] is o[b] rule
that exists today (modulo tiny values) for numbers a and b, when
extended to decimals a and b.
Intuition is a very tricky thing. Place the following in front of any third grader, and tell me what they will write below the line.
1 . 0 5
- 2 . 0 5
Of course the result should be 3.10 on paper, but this does not say
that ToString applied to decimal must preserve scale digits.
One alternative is to distinguish the operation used when computing a
property name from the ToString used everywhere else, and make the
former lose scale digits while the latter preserves them. There's no
doubt a 754r method for converting to string without trailing zeroes
or otherwise preserving scale (those funny exponents Waldemar decried).
If we did this, we would have to complicate the spec by adding a
special case to its computed property name logic. And users wishing
to mimick it with explicit conversion to a string would not be able
to use String(d) or "" + d -- they would have to call the other method.
Brendan Eich wrote:
On Sep 23, 2008, at 1:45 PM, Waldemar Horwat wrote:
Sam Ruby wrote:
One minor request: statements like "breaks arrays" are less helpful than specific ECMAScript statements which would fail; better yet
would be citing specific deployed code that would fail. I already gave specific examples of this and we've had extensive
discussions of them. I don't like beating a dead horse any more
than necessary.The horse must not be dead. The question is: should a === b imply o [a] and o[b] refer to the same property, for any object o (modulo the
spec bug that David Jones pointed out whereby 5e-324 could be
converted to strings such as "3e-324" and "7e-324").Sam seems to think a === b should not imply o[a] and o[b] refer to
the same property (double-cited text is from Jason Orendorff):Well, the intuition is that two equal numbers should index the same property. This is an invariant in ES3 and it makes a lot of sense. Correct me if I'm wrong, but the intuition would more properly be
based on string equality, and not numeric equality. As an example, how many properties would the following produce, with an conformant implementation of ES3?var a = []; a['0.0'] = "first"; a[0.0] = "second"; // a second property a['0'] = "third"; // replaces second property
The intuition depends on string equality and ToString in addition to
numeric equality. But it turns out that a === b for any numbers a and
b implies ToString(a) === ToString(b) (except, again, for the very
small numbers David Jones pointed out).But Sam's decimal implementation has 1.1m === 1.10m.
So the precise issue with "breaks arrays" is the proposal from Sam
and Mike that ToString on a decimal preserve scale digits (I hope I'm
using the right term). That breaks the a === b => o[a] is o[b] rule
that exists today (modulo tiny values) for numbers a and b, when
extended to decimals a and b.
At the present time, strictly equals is approximately the "Object.eq". There is no question that a.eq(b) => o[a] is o[b].
Permit me to be so bold as to propose a Gedanken Experiment?
Is it ever anticipated that future editions of ECMAScript will allow users to provide via multimethods alternative implementations for either double equals or triple equals?
Intuition is a very tricky thing. Place the following in front of any third grader, and tell me what they will write below the line.
1 . 0 5
- 2 . 0 5
Of course the result should be 3.10 on paper, but this does not say
that ToString applied to decimal must preserve scale digits.One alternative is to distinguish the operation used when computing a
property name from the ToString used everywhere else, and make the
former lose scale digits while the latter preserves them. There's no
doubt a 754r method for converting to string without trailing zeroes
or otherwise preserving scale (those funny exponents Waldemar decried).If we did this, we would have to complicate the spec by adding a
special case to its computed property name logic. And users wishing
to mimick it with explicit conversion to a string would not be able
to use String(d) or "" + d -- they would have to call the other method.
Good summary.
/be
- Sam Ruby
Sam Ruby wrote:
Brendan Eich wrote: [...]
The intuition depends on string equality and ToString in addition to
numeric equality. But it turns out that a === b for any numbers a and
b implies ToString(a) === ToString(b) (except, again, for the very
small numbers David Jones pointed out).But Sam's decimal implementation has 1.1m === 1.10m.
So the precise issue with "breaks arrays" is the proposal from Sam
and Mike that ToString on a decimal preserve scale digits (I hope I'm
using the right term). That breaks the a === b => o[a] is o[b] rule
that exists today (modulo tiny values) for numbers a and b, when
extended to decimals a and b.At the present time, strictly equals is approximately the "Object.eq". There is no question that a.eq(b) => o[a] is o[b].
Permit me to be so bold as to propose a Gedanken Experiment?
Is it ever anticipated that future editions of ECMAScript will allow users to provide via multimethods alternative implementations for either double equals or triple equals?
'==': that would potentially be useful, and I wouldn't want to rule it out at this stage (even though I'm not a particular fan of multimethods as they are defined in existing languages).
Object.eq: no by definition. An EQ operation has a fixed semantics that tests identity without consulting its arguments or being overridable depending on their type.
'===': that depends whether we want '===' to continue to be an approximation of EQ, with 0, -0, and NaN as the only special cases.
I have uploaded to the wiki (linkes3.1:es3.1_proposal_working_draft) the 22 Sep 2008 draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. Revision history is at the end of the document.
This shall be the document to use for review at the upcoming TC39 meeting (24/25/26 Sep, Microsoft, Redmond). If there are any updates or revisions prior to the meeting, we will post them on the wiki as well as on the discuss lists.
pratap