Mark S. Miller
erights at google.com
Wed Sep 17 18:22:08 PDT 2008
On Wed, Sep 17, 2008 at 2:18 PM, Sam Ruby <rubys at intertwingly.net> 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.
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss