On Wed, Sep 17, 2008 at 2:18 PM, Sam Ruby <[EMAIL PROTECTED]> wrote: > > To the extent that I understand Doug's proposal, it essentially is an > opt-in that would remove a feature (binary64 floating points); and > therefore would likely be about as successful as an opt-in that > removed another feature that Doug dislikes, such as "with". Am I > missing something? >
Without advocating either Crock's or Sam's positions on "use decimal", I will take issue with the above. Proposed ES3.1 "use strict" is an opt-in that will remove "with", "delete <var>", eval-operator exporting bindings to its calling context, "arguments.callee", "arguments.caller", joining of arguments with parameter variables, "Function.caller", and "Function.arguments". That's why it's opt-in. Genuine improvements which are purely additive (rare though they may be) are upwards compatible, and so need not be contingent on opt-in. My own position on decimal: * I agree with Brendan and Crock that Decimal should wait until after 3.1. That said, I think Sam is doing a great job refining the proposal, taking into account all objections, and producing code people can test and incorporate. I agree that the status of engineering quality here is well ahead of most of what this committee has ever produced. We would all do well to emulate Sam's example. * Between Crock's and Sam's present proposals, I prefer Sam's. * Given that we leave compareTotal out of EcmaScript, IIUC, the operational semantics of Sam's proposed decimal in EcmaScript would have only one NaNm, Inifinitym, and -Infinitym, just as EcmaScript binary floating point only has one NaN, Infinity, and -Infinity. Given that, I have no further specific objections to Sam's proposal. I'd just like to see it wait till after 3.1. * Please let us never refer to the result of decimal as "correct". If it were possible for computers to implement arithmetic correctly in finite time and space, we wouldn't be in this mess. The best that can be said of decimal is that it is incorrect in ways that people find more intuitive. * Like Crock, I prefer that typeof 1m === 'number'. However, unlike Crock's and Brendan's agreement, I think this should be unconditional. I think it would be horrible for 'typeof X' to depend not only on the value of X but also on the mode of the program unit in which the typeof appears. Please don't do that. Let's examine the case against: On Wed, Sep 17, 2008 at 12:49 PM, Brendan Eich wrote: > On Sep 17, 2008, at 6:54 PM, Douglas Crockford wrote: > > > It requires that a === b produce the same result as > > typeof a == typeof b && a == b. Agreed. > Without "use decimal", typeof 1.1m must not be "number" to preserve > this same invariant. Otherwise (without "use decimal") 1.5m == 1.5 > but 1.1m != 1.1, so without making typeof 1.5m != typeof 1.1m, we > cannot have typeof 1.5m == "number". > > I do not believe anyone wants typeof 1.5m != typeof 1.1m. I agree that typeof 1.5m == typeof 1.1m. However, I do not agree that 1.1m == 1.1. These should be !=, since they represent distinct real numbers. I do agree that 1.5m == 1.5, but only because they represent the same real number, not because they look the same. This extends the notion of cohort across the decimal/binary divide. -0, 0, -0m, 0m, 0.000m may all be computationally distinct values. (Is 0.00m distinct from 0m?) If they are, then they should therefore be distinguished by any Object.identical() and Object.indentityHash() operations. But they all represent the same real number, so they should be ==. If we agree that they should also all be typeof 'number', then they should also all be === and be considered generalized cohorts. If typeof all these were 'number', then binary and decimal could share a single NaN, Infinity, and -Infinity. Only the remaining finite numeric values would be distinctly either binary or decimal. I agree with Sam and apparently Crock and everyone else that mixed mode should coerce to decimal. Or, at least, I have no objection to that position. Were we to adopt this, then I think "use decimal" should condition only whether an unqualified numeric literal be interpreted as binary or decimal floating point. We should then have a suffix which means binary floating point, so you can say it explicitly. Nothing else about the numerics should be conditioned by the pragma. -- Cheers, --MarkM
_______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
