Es-discuss - several decimal discussions
brendan at mozilla.org
Sat Aug 23 23:14:02 PDT 2008
On Aug 23, 2008, at 5:45 PM, ihab.awad at gmail.com wrote:
> On Sat, Aug 23, 2008 at 11:30 AM, Sam Ruby <rubys at intertwingly.net>
>> Having Decimal.parse(2) + 3 produce "23" is not what I would call
>> fast", as that is a term I would typically use for throwing an
>> exception or
>> the like.
> Point well taken. Does Maciej's followup regarding valueOf throwing
> solve the problem?
It forces would-be Decimal users to call Decimal.add(Decimal.parse(s)
+ 3) (let's say s may or may not be 2 or "2"). Is that a solution for
ES3.1? It's user-hostile instead of future-hostile.
Can we not do better, especially by not overconstraining the problem
by subjecting its solution to the ES3.1 goals and schedule?
> Were ES designed, back in 1995, to be the language it has become, and
> were there time back then to have thought about how the builtin
> arithmetic and comparison generalizes to mixtures of decimals,
> arbitrary precision integers, complex numbers, matrices and
> polynomials, I would agree with you unequivocally. As matters stand,
> I'm not so sure.
I've been through as many what-if's and might-have-been's as anyone.
JS clearly had too much implicit magic -- Perl-envy, if you will --
to be as neatly extensible as we want, in hindsight.
EIBTI, the Pythonistas say. But this need not mean explicit method
calls instead of operators for any numeric extension, since that's
pretty much unusable (except under SOX mandate :-/).
We've often cited EIBTI in ES4 working group meetings. In general I
daresay the TC39 committee is more in favor of avoiding implicit
magic, especially conversions, now than ever (E4X, ECMA-357, is full
of it, and it's a mess). But this doesn't mean that throwing when a
Decimal is used in any not-guaranteed-to-be-numeric operand context
>> It would not be wise for equality operators, in particular, to
>> start throwing exceptions.
> Could these operators simply be consistent with "===" for any user
> defined library type, and something else (a ".equals()" operator, say)
> be used to define value equality?
That's incompatible, and the double-dispatched (for dyadic operators)
method mapping is something we'd like to avoid in the future
> Once again, Java faced this same problem in adding BigDecimal -- and
> Java is strongly typed and so arguably had more leeway to add rules
> that make it clearer to programmers what was going on. Yet their
> solution was to simply create classes at the library level.
BigMistake, as Cameron blogged. Java failed, C# ruled here.
> I think the Java analogue is instructive. In Java, primitives and
> objects are distinct.
That's a botch, one I copied in a hurry in 1995 and regret. I should
have stuck to the Self and Smalltalk sources of inspiration, but JS
had to "look like Java" and it was easier both to implement, and to
think about JS/Java bridging (LiveConnect, so-called), if I
distinguished primitive string, boolean, and number from their object
> BigDecimal was apparently a clumsy enough entity
> that it was found to need implementation as a constructed object.
This "apparently" backward-reasoning phenomenology is flawed.
Implementors can work harder so programmers don't have to. There's no
technical reason that decimal has to be a non-primitive in any
language that distinguishes primitive types from first-class object
types, any more than there is for strings to be non-primitive.
> ES, everything is an object yet there are primitive types; this means
> that, when faced with a newly required constructed object type, we are
> tempted to slip it in as a new primitive. In the absence of extensive
> planning done back in the mid 1990s, I submit that the temptation is
> to be resisted.
What extensive planning do you mean? Oh, the lack of it when I
Sorry, this is bogus arguing too :-|. Five-year plans are no
guarantee of success. Utopia is not an option. Lots of underused
languages have over-planned designs and nevertheless have big
problems (other than lack of users).
Anyway, languages that do succeed in gaining users inevitably grow.
Growing a language is hard but possible. Python grew, including in
its numeric model and operators. In spite of harsher backward
compatibility constraints, so too can JS.
IEEE double is not the only conceivable number type, and indeed 32-
bit int and unsigned int show through in places in JS (bitwise
operators, array length). I'm not in favor of more machine types. But
I think making more BigMistakes with methods only, no operators, is
guaranteed to keep IEEE double the only number type that's actually
used by most real-world JS programmers.
More information about the Es-discuss