Es-discuss - several decimal discussions

Brendan Eich brendan at
Sat Aug 23 23:14:02 PDT 2008

On Aug 23, 2008, at 5:45 PM, ihab.awad at wrote:

> On Sat, Aug 23, 2008 at 11:30 AM, Sam Ruby <rubys at>  
> wrote:
>> Having Decimal.parse(2) + 3 produce "23" is not what I would call  
>> "fail
>> 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  
is good.

>> 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  
(wherefore multimethods).

> 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  
wrapper types.

> 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.

> In
> 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  
created JS.

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 mailing list