Why decimal?

[Christian Plesner Hansen-3]

I've been looking around on the web for reasons why decimal arithmetic
should be added to ES.  The most extensive page I could find was
http://speleotrove.com/decimal/decifaq.html.  If anyone know other
good sources of information about decimal and its inclusion in ES
please follow up.

The strongest argument seems to be financial: binary arithmetic is
approximate in a way that makes it unsuitable for financial
calculations.  I buy this argument in general -- I would definitely
want my bank to use some form of decimal arithmetic rather than binary
-- but less so in the context of ES.  A while ago we (the v8 team)
asked around within google and were unable to find anyone who would
want to do financial calculations client-side.  Financial calculations
are sensitive and keeping it on the server makes it possible to
maintain consistency, accountability, testability and reproducibility.
 So while I'm all for decimal in languages that run server side it's
much less relevant for a language that runs almost exclusively on the
client.

Another data point is that the one decimal library that exists for JS,
a direct translation from Java's BigDecimal, hasn't been updated since
2000, during which time a number of bugs have been fixed in Java
BigDecimal.  If there had been a broad interest in using a JS decimal
library I would expect there to be a well-maintained one around.

I found a handful of blog posts supporting decimal from an accuracy
standpoint -- essentially "0.1 + 0.2 should be equal to 0.3".  The
argument looks compelling but is somewhat misleading.  All floating
point arithmetic is approximate.  K-bit decimal arithmetic trades
smaller but conspicuous inaccuracies for greater but less conspicuous
ones when compared with k-bit binary.  In some contexts, financial
again for instance, the accuracy argument makes sense but not as a
general statement without qualification.  Nonetheless, far as I can
tell this is the source of a large portion of the requests for
supporting decimal.  Furthermore, decimal itself is counter-intuitive
in a number of ways: the difference between 1e2 and 100, for instance,
is counter-intuitive in many contexts.  I know the most obvious
differences have been removed from the ES proposal; I'm not sure if
there are less obvious differences left (like with +/-0).

Another problem is that the standard is closed: I can't even read it
without paying for it. Granted, that also holds for the specification
of double but with double there is universal native support, we don't
have to maintain an implementation ourselves.  That's not the case for
decimal.  We as implementers of the language would have to potentially
create or at least maintain an implementation of a closed standard.

Finally, the usefulness of decimal either a native implementation or a
library would have to be weighed against the increase in the size of
the implementation.  The fact that JS is becoming increasingly popular
on limited devices speaks against adding a large decimal library.


-- Christian
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 23, 2009, at 12:18 AM, Christian Plesner Hansen wrote:

I've been looking around on the web for reasons why decimal arithmetic
should be added to ES.  The most extensive page I could find was
http://speleotrove.com/decimal/decifaq.html.  If anyone know other
good sources of information about decimal and its inclusion in ES
please follow up.

Mike Cowlishaw's pages on decimal have lots of arguments for it:

http://www2.hursley.ibm.com/decimal/decifaq.html

http://www2.hursley.ibm.com/decimal/

The most-duplicated JS bug in bugzilla.mozilla.org is

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

Here's a typical naive JS user complaining that his computer his broken because it can't calculate correct differences:

"... I typed in:

9533.24-215.10

… and here is the garbage Apple babbled back at me: 9318.139999999999"

He blamed Apple. Naive users often blame hardware for software bugs.

The strongest argument seems to be financial: binary arithmetic is
approximate in a way that makes it unsuitable for financial
calculations.  I buy this argument in general -- I would definitely
want my bank to use some form of decimal arithmetic rather than binary
-- but less so in the context of ES.

Do you consider that naive user's calculator example to be "financial"? I do not.

The problem is worse for non-experts. The experts can cope.

Anyway, decimal is not being pushed into JS at this point. At the last face-to-face TC39 meeting, we changed direction to explore generalizing value type support (including operators and literals if we can) so that libraries could add first class number-like types.

Whether any new value type would be native or self-hosted, and whether it would be included in the core standard, are issues we want to defer until later, ideally until there are de-facto standards to codify.

The counter-argument articulated at the meeting by Sam was that it's rare for users to download binary extensions to JS for browsers (Flash is the only exception, and it's not primarily a JS extension). So users won't get decimal unless it is part of the normative core spec, so the usability bug reported as Mozilla bug 5856 won't get fixed.

I think Sam has a point; lack of a standard could be a problem. But whatever we do about it, the committee agreed to work on value types first. They're on the Harmony agenda.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Ash Berlin-3]

On Tue, 23 Jun 2009 09:18:16 +0200, Christian Plesner Hansen
<christian.plesner.hansen@...> wrote:

> I've been looking around on the web for reasons why decimal arithmetic
> should be added to ES.  The most extensive page I could find was
> http://speleotrove.com/decimal/decifaq.html.  If anyone know other
> good sources of information about decimal and its inclusion in ES
> please follow up.
>
> The strongest argument seems to be financial: binary arithmetic is
> approximate in a way that makes it unsuitable for financial
> calculations.  I buy this argument in general -- I would definitely
> want my bank to use some form of decimal arithmetic rather than binary
> -- but less so in the context of ES.  A while ago we (the v8 team)
> asked around within google and were unable to find anyone who would
> want to do financial calculations client-side.

Java/ECMAScript is not only run inside a web browser.
http://wiki.mozilla.org/ServerJS

Personally I am entierly ambivelent to decimal.

I'd rather it was possible to do operator overloading such that decial or
what ever else could be implemented natively (in a self hosting JS) but I
can also accept that this (operator overloading) is unlikely to happen.

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 23, 2009, at 9:28 AM, Ash Berlin wrote:

> I'd rather it was possible to do operator overloading such that  
> decial or
> what ever else could be implemented natively (in a self hosting JS)  
> but I
> can also accept that this (operator overloading) is unlikely to  
> happen.

Au contraire, as I noted in reply to Christian -- it's on the Harmony  
agenda:

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

Mark M. took the action to write the spec, he already posted his  
operator proposal to this list, here:

https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html

I'm signed up to help Mark (as time allows, definitely in July; new  
baby at home).

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

> Do you consider that naive user's calculator example to be "financial"? I do
> not.

I don't know, the user doesn't say why this inaccuracy is a problem.
It sounds like he's just generally unhappy that arithmetic is
approximate.  Decimal is approximate too.  Unless the example is set
in a context where we know we'll stay in base 10, such as financial,
decimal arithmetic will only give you less accuracy per bit.

> The counter-argument articulated at the meeting by Sam was that it's rare
> for users to download binary extensions to JS for browsers (Flash is the
> only exception, and it's not primarily a JS extension). So users won't get
> decimal unless it is part of the normative core spec, so the usability bug
> reported as Mozilla bug 5856 won't get fixed.

As far as I can see none of the reports collected under 5856 ask for
decimal, what they ask for is accurate arithmetic.  Decimal doesn't
provide that.  If people were asking for decimal arithmetic because
they needed it for some particular financial or scientific application
then that would be different.

> I think Sam has a point; lack of a standard could be a problem. But whatever
> we do about it, the committee agreed to work on value types first. They're
> on the Harmony agenda.

Are there any other uses planned for value types than decimal?


-- Christian
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 23, 2009, at 10:10 AM, Christian Plesner Hansen wrote:

>> Do you consider that naive user's calculator example to be  
>> "financial"? I do
>> not.
>
> I don't know, the user doesn't say why this inaccuracy is a problem.
> It sounds like he's just generally unhappy that arithmetic is
> approximate.  Decimal is approximate too.

That's true at very extreme margins only! Decimal does not fail to  
round power-of-five products so badly, and I think you know this.

13+ years ago, I got a bug report about this calculation:

js> 79.46-39.96
39.49999999999999

This was before we founded mozilla.org, it was about Netscape 2 or 3.  
So the bug report prefigured bug 5856.

These dollars and cents calculations are quite common, and decimal  
handles them correctly with full precision and no rounding errors.


>  Unless the example is set
> in a context where we know we'll stay in base 10, such as financial,
> decimal arithmetic will only give you less accuracy per bit.

Why are you talking about "bits" here?

Base 2 and base 5 are different, and finite precision in the latter  
(or base 10) can represent numbers exactly, for which no exact  
representation exists or can be rounded nicely using base 2 with any  
finite precision.


> As far as I can see none of the reports collected under 5856 ask for
> decimal, what they ask for is accurate arithmetic.  Decimal doesn't
> provide that.  If people were asking for decimal arithmetic because
> they needed it for some particular financial or scientific application
> then that would be different.

See above. I think you are missing something fundamental about the  
problem reported at that bug. Decimal does fix it for the use-cases  
reported there and in dups.


> Are there any other uses planned for value types than decimal?

Sure: point, rational, complex, RGBA color, quaternion, .... Some of  
these are esoteric, scientific programmers may care (game programmers  
too). Others are pretty common on the web.

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Ash Berlin-3]

On 23 Jun 2009, at 17:59, Brendan Eich wrote:

> On Jun 23, 2009, at 9:28 AM, Ash Berlin wrote:
>
>> I'd rather it was possible to do operator overloading such that  
>> decial or
>> what ever else could be implemented natively (in a self hosting JS)  
>> but I
>> can also accept that this (operator overloading) is unlikely to  
>> happen.
>
> Au contraire, as I noted in reply to Christian -- it's on the  
> Harmony agenda:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:strawman
>
> Mark M. took the action to write the spec, he already posted his  
> operator proposal to this list, here:
>
> https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html
>
> I'm signed up to help Mark (as time allows, definitely in July; new  
> baby at home).
>
> /be

Awesome. I noticed that after I'd already send my previous response.

This doesn't get said enough: good work guys.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Michael Daumling-2]

Mark's proposal is very close to something I proposed long ago, but was rejected. It has been implemented in Adobe's ExtendScript dialect, with a slight variation (instead of ['reverse+'], a second Boolean argument to the overload implementation indicates reverse operation).

Funny how things keep popping up.

Michael

-----Original Message-----
From: es-discuss-bounces@... [mailto:es-discuss-bounces@...] On Behalf Of Ash Berlin
Sent: Tuesday, June 23, 2009 1:51 PM
To: es-discuss
Subject: Re: Why decimal?


On 23 Jun 2009, at 17:59, Brendan Eich wrote:

> On Jun 23, 2009, at 9:28 AM, Ash Berlin wrote:
>
>> I'd rather it was possible to do operator overloading such that  
>> decial or
>> what ever else could be implemented natively (in a self hosting JS)  
>> but I
>> can also accept that this (operator overloading) is unlikely to  
>> happen.
>
> Au contraire, as I noted in reply to Christian -- it's on the  
> Harmony agenda:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:strawman
>
> Mark M. took the action to write the spec, he already posted his  
> operator proposal to this list, here:
>
> https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html
>
> I'm signed up to help Mark (as time allows, definitely in July; new  
> baby at home).
>
> /be

Awesome. I noticed that after I'd already send my previous response.

This doesn't get said enough: good work guys.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

>> I don't know, the user doesn't say why this inaccuracy is a problem.
>> It sounds like he's just generally unhappy that arithmetic is
>> approximate.  Decimal is approximate too.
>
> That's true at very extreme margins only! Decimal does not fail to round
> power-of-five products so badly, and I think you know this.

I know, and just after what you quoted I said "unless we know we'll
stay in base 10".  It's a fact that if you venture outside of base 10
you'll get more accurate results using k-bit binary than k-bit
decimal.

> 13+ years ago, I got a bug report about this calculation:
>
> js> 79.46-39.96
> 39.49999999999999

A single approximate calculation doesn't say anything about how the
user would like arithmetic to behave generally.  Using any type of
floating-point numbers properly is not easy and the right solution
depends on your setting.  If this is dollar amounts maybe calculating
with integer cents is a better solution.  It's impossible to tell from
one isolated calculation what the right solution is since we don't
know why the inaccuracy is a problem.  We can guess that maybe decimal
is the solution this user is looking for.  Our experience from asking
around within google, and looking at the one decimal library
available, says that the interest in decimal is very limited in
practice.

> These dollars and cents calculations are quite common, and decimal handles
> them correctly with full precision and no rounding errors.

In which contexts do people perform these casual dollars-and-cents
calculations in JS?  I would expect the vast majority of
dollars-and-cents calculations to happen in the kind of setting I
argued in my original mail would most likely take place on the server
even if there was decimal support on the client.

>>  Unless the example is set
>> in a context where we know we'll stay in base 10, such as financial,
>> decimal arithmetic will only give you less accuracy per bit.
>
> Why are you talking about "bits" here?

To signify that I'm comparing 64-bit binary with 64-bit decimal or
128-bit ditto, but not 64-bit binary and 128-bit decimal.

>> As far as I can see none of the reports collected under 5856 ask for
>> decimal, what they ask for is accurate arithmetic.  Decimal doesn't
>> provide that.  If people were asking for decimal arithmetic because
>> they needed it for some particular financial or scientific application
>> then that would be different.
>
> See above. I think you are missing something fundamental about the problem
> reported at that bug. Decimal does fix it for the use-cases reported there
> and in dups.

Which kind of arithmetic is appropriate depends on what your setting
is.  Hardly any of these bug reports give any context so there is no
way to tell if decimal will solve people's problems.  Here's a few
dups where it definitely won't:

https://bugzilla.mozilla.org/show_bug.cgi?id=356566
"The Javascript modulus arithmetic has gross errors when large numbers
are used "

https://bugzilla.mozilla.org/show_bug.cgi?id=369803
"When doing lots of small scale and translation equations I start
getting rounding errors."


-- Christian
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

>> That's true at very extreme margins only! Decimal does not fail to round
>> power-of-five products so badly, and I think you know this.
>
> I know, and just after what you quoted I said "unless we know we'll
> stay in base 10".  It's a fact that if you venture outside of base 10
> you'll get more accurate results using k-bit binary than k-bit
> decimal.

Just to avoid confusion: when I say base 10 I mean numbers like 0.1
and 1343.41 as opposed to 1/3 and pi.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Breton Slivka]

People generally expect math to work how they've been taught in
school. When javascript violates their expectations, that is the very
definition of a bug.

It is true that binary might be more precise for certain kinds of
applications, and if it's a native machine type there's performance
advantages.

 These are facts that a novice programmer does not know or care about
in the slightest. All they know is that even their desktop calculator
can do this work properly, it must be javascript, or apple, or
whatever that is broken. This is obvious to anyone that doesn't look
at the world through nerd colored glasses. It's a fact so painful that
microsoft even went to the trouble of pouring in an epic amount of
research and development into their calc.exe so it doesn't display
this broken looking behavior, as it displayed in earlier versions. A
programmer might take the trouble to learn these esoteric computer
facts, but end users won't.

A less informed programmer might not even notice anything is wrong,
until some unsuspecting user comes across it. Depending on the
programmer, they may not know how to deal with it.

And finally, it's highly likely that javascript will be used more and
more on the server side in years to come, so javascript being a
"client side" language no longer works as a credible excuse.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

> People generally expect math to work how they've been taught in
> school. When javascript violates their expectations, that is the very
> definition of a bug.

School math is accurate, there are no approximations at all.  Neither
binary nor decimal are accurate, both will violate people's
expectations of accuracy.  If you do (1.0 / 3.0) * 3.0 neither binary
nor decimal give you 1.0.

>  These are facts that a novice programmer does not know or care about
> in the slightest. All they know is that even their desktop calculator
> can do this work properly, it must be javascript, or apple, or
> whatever that is broken. This is obvious to anyone that doesn't look
> at the world through nerd colored glasses. It's a fact so painful that
> microsoft even went to the trouble of pouring in an epic amount of
> research and development into their calc.exe so it doesn't display
> this broken looking behavior, as it displayed in earlier versions. A
> programmer might take the trouble to learn these esoteric computer
> facts, but end users won't.

If you're doing a calculator application you can use a decimal
library.  I'm not saying that decimal can't ever be useful, what I'm
saying is: it's not useful enough that we want to force all
implementations to include it.

> And finally, it's highly likely that javascript will be used more and
> more on the server side in years to come, so javascript being a
> "client side" language no longer works as a credible excuse.

Server side JS is a different situation and much easier.  On the
server you control the implementation you use.  Since JS lacks any way
to interact with its surroundings out of the box you're already more
or less forced to extend your implementation to be able to do
something meaningful.  If you want decimal arithmetic on the server
you're free to add it, either as a library or as a native extension.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

> School math is accurate, there are no approximations at all.  Neither
> binary nor decimal are accurate, both will violate people's
> expectations of accuracy.  If you do (1.0 / 3.0) * 3.0 neither binary
> nor decimal give you 1.0.

D'oh!  I just tried this and it actually gives 1.0 using both 32-bit
and 64-bit binary arithmetic.  But it's easy to construct examples
where none of the systems are accurate, for instance

  x = 2/3
  print((0.5 + x) - x);

This gives, depending on which arithmetic system you use:

  128-bit decimal: 0.5000000000000000000000000000000003
  64-bit binary: 0.4999999999999999
  64-bit decimal: 0.5000000000000003
  32-bit binary: 0.50000006

Using school math you would expect that adding and then subtracting
the same number would get you back where you started.  Decimal is a
counter-intuitive as binary in that respect.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Douglas Crockford]

Breton Slivka wrote:
> People generally expect math to work how they've been taught in
> school. When javascript violates their expectations, that is the very
> definition of a bug.

Truly. The issue isn't "Why decimial?" It is "How decimal?" and perhaps "Which
decimal?"
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 24, 2009, at 1:49 AM, Christian Plesner Hansen wrote:

>>> I don't know, the user doesn't say why this inaccuracy is a problem.
>>> It sounds like he's just generally unhappy that arithmetic is
>>> approximate.  Decimal is approximate too.
>>
>> That's true at very extreme margins only! Decimal does not fail to  
>> round
>> power-of-five products so badly, and I think you know this.
>
> I know, and just after what you quoted I said "unless we know we'll
> stay in base 10".  It's a fact that if you venture outside of base 10
> you'll get more accurate results using k-bit binary than k-bit
> decimal.

If a computation favors base 3 or base 7, you're right -- no one radix  
fits all cases when precision is finite. But people have 10 fingers,  
and they expect sums and differences to work the way they learned on  
paper.

Your mode of argument makes it sound like each radix is equally likely  
to be best, that base 10 is not privileged in everyday practice -- or  
from your "k-bit binary" remark, that Shannon's ghost is whispering  
"base e is best, approximate with base 2 or 3!" :-P

Most users do not know and do not care about information theory  
optimality, they just want sums and differences to "work".

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[P T Withington]

On 2009-06-24, at 11:08EDT, Brendan Eich wrote:

> Most users do not know and do not care about information theory  
> optimality, they just want sums and differences to "work".

Don't most users really want rational numbers, plus a way to present  
them to a certain level of precision?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Jun 24, 2009, at 8:16 AM, P T Withington wrote:

> On 2009-06-24, at 11:08EDT, Brendan Eich wrote:
>
>> Most users do not know and do not care about information theory  
>> optimality, they just want sums and differences to "work".
>
> Don't most users really want rational numbers, plus a way to present  
> them to a certain level of precision?

Could be, which is why we are pursuing value types with extensible  
operators and literal notation.

I have concluded that it's too late to "fix" anything by adding  
decimal. It's clearly to late to change the number type from binary to  
decimal. So we are going to let library authors cater to users, and  
get TC39 out of this hopeless business.

/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Mark S. Miller-2]

On Wed, Jun 24, 2009 at 8:21 AM, Brendan Eich <brendan@...> wrote:

I have concluded that it's too late to "fix" anything by adding decimal. It's clearly to late to change the number type from binary to decimal. So we are going to let library authors cater to users, and get TC39 out of this hopeless business.

+1

--
   Cheers,
   --MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Christian Plesner Hansen-3]

> I have concluded that it's too late to "fix" anything by adding decimal.
> It's clearly to late to change the number type from binary to decimal. So we
> are going to let library authors cater to users, and get TC39 out of this
> hopeless business.

Sorry for being slow but I'm a little unclear on what that means.
Does it mean that you're not in favor of including decimal in harmony?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Erik Corry-2]

2009/6/23 Brendan Eich <brendan@...>

On Jun 23, 2009, at 12:18 AM, Christian Plesner Hansen wrote:

I've been looking around on the web for reasons why decimal arithmetic
should be added to ES.  The most extensive page I could find was
http://speleotrove.com/decimal/decifaq.html.  If anyone know other
good sources of information about decimal and its inclusion in ES
please follow up.

Mike Cowlishaw's pages on decimal have lots of arguments for it:

http://www2.hursley.ibm.com/decimal/decifaq.html

http://www2.hursley.ibm.com/decimal/

I'm afraid both these links seem to have broken.
 

The most-duplicated JS bug in bugzilla.mozilla.org is

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

Here's a typical naive JS user complaining that his computer his broken because it can't calculate correct differences:

"... I typed in:

9533.24-215.10

… and here is the garbage Apple babbled back at me: 9318.139999999999"

He blamed Apple. Naive users often blame hardware for software bugs.

The strongest argument seems to be financial: binary arithmetic is
approximate in a way that makes it unsuitable for financial
calculations.  I buy this argument in general -- I would definitely
want my bank to use some form of decimal arithmetic rather than binary
-- but less so in the context of ES.

Do you consider that naive user's calculator example to be "financial"? I do not.

The problem is worse for non-experts. The experts can cope.

Anyway, decimal is not being pushed into JS at this point. At the last face-to-face TC39 meeting, we changed direction to explore generalizing value type support (including operators and literals if we can) so that libraries could add first class number-like types.

Whether any new value type would be native or self-hosted, and whether it would be included in the core standard, are issues we want to defer until later, ideally until there are de-facto standards to codify.

The counter-argument articulated at the meeting by Sam was that it's rare for users to download binary extensions to JS for browsers (Flash is the only exception, and it's not primarily a JS extension). So users won't get decimal unless it is part of the normative core spec, so the usability bug reported as Mozilla bug 5856 won't get fixed.

I think Sam has a point; lack of a standard could be a problem. But whatever we do about it, the committee agreed to work on value types first. They're on the Harmony agenda.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss