Es-discuss - several decimal discussions
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>
>>> Finally, I'd like to take a poll: Other than people working on
>>> at IBM and people on the EcmaScript committee, is there anyone on
>>> 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?
(especially the first comment, by Bob McWhirter)
All linked from the still-useful
> 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
> 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
> 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
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 :-/.
More information about the Es-discuss