Es-discuss - several decimal discussions

Brendan Eich brendan at mozilla.org
Sat Aug 23 19:39:15 PDT 2008


On Aug 23, 2008, at 8:44 AM, ihab.awad at gmail.com wrote:

> On Sat, Aug 23, 2008 at 1:49 AM, Mike Cowlishaw <MFC at uk.ibm.com>  
> wrote:
>>> Finally, I'd like to take a poll: Other than people working on  
>>> decimal
>>> at IBM and people on the EcmaScript committee, is there anyone on  
>>> this
>>> list who thinks that decimal adds significant value to  
>>> EcmaScript? If
>>> so, please speak up. Thanks.
>>
>> Decimal arithmetic is sufficiently important that it is already
>> available in all the 'Really Important' languages except ES
>> (including C, Java, Python, C#, COBOL, and many more).  EcmaScript is
>> the 'odd one out' here, and not having decimal support makes it
>> terribly difficult to move commercial calculations to the browser for
>> 'cloud computing' and the like.
>
> Decimals in Java are implemented at the library level, as
> java.math.BigDecimal. There is no expectation that intrinsic math
> operators work on them. Is this approach valid for ES; if not, then
> why not?

See

http://jroller.com/cpurdy/entry/the_seven_habits_of_highly1  
(especially the first comment, by Bob McWhirter)

also see

https://bugzilla.mozilla.org/show_bug.cgi?id=5856

All linked from the still-useful

http://wiki.ecmascript.org/doku.php?id=discussion:decimal


> Implementing decimals at the library level has the advantage that they
> can be deployed today, as functional (if slower) ES code, and
> optimized later on by a native implementation with no loss of
> compatibility.

http://gwt-math.googlecode.com/svn/trunk/gwt-math/src/main/resources/ 
com/googlecode/gwt/math/public/js/bigdecimal.js

;-)


> After all, it will be several years before the next ES
> version becomes reliably available on consumers' browsers.

Several years or less than a year from final spec, depending on the  
vendor's commitments to standards.


> Does this
> manner of easing migration inform the approach being taken?

Not really. If you want GWT, use it. If you want a library, they are  
out there. The problem is making a new type in ES3.1's spec work,  
both now and in the future when operators are added (so we can avoid  
the laughable but totally predictable outcome Bob McWhirter cited in  
Purdy's blog).


> Conversely, if one is to add support for the intrinsic math operators
> on decimals, does the required work generalize easily to arithmetic on
> complex numbers and matrices?

We might hope to know by looking at other languages, but really,  
doing the work in the context of backward JS compatibility is  
required. So again, doing what Sam is doing in developing patches  
against open source JS implementations seems at least as valuable as  
trying to spec Decimal quickly, making it "law", and then hoping it  
works out in the future *and* somehow leads to a taller numeric tower.


> Will the addition of complex numbers and
> matrices require more difficult work about how they interoperate with
> existing number representations (including, at that point, decimal
> numbers)? How, if at all, does this inform the present discussion?

You might find

http://wiki.ecmascript.org/doku.php?id=proposals:generic_functions

interesting. Obviously not a live proposal, but if we ever want  
operators, I'm still in favor of multimethods instead of hardcoding.  
The current untestable spec can't stand much more complexity in its  
runtime semantics. If we ever get complex numbers, quaternions, etc.,  
they should come by users defining operator multimethods after the  
committee has retired in victory to the same Valhalla where Dylan and  
Cecil are spoken :-/.

/be



More information about the Es-discuss mailing list