On Aug 15, 2011, at 10:33 AM, David Bruant wrote:
> Hi,
>
> I have been watching JSConf talks recently and two of them [1] [2]
> mentionned the issue that JavaScript has with numbers. Something than
> prevent JS to be a good language to interact with a database. The lack
> of 64-bits integers is also mentioned.
The last is a sore point that I hope binary_data (in ES6) will address, on the
storage-type side. As far as 64-bit arithmetic, without value types we would
have to use a module of functions to call by awkward names: add, sub, etc. if
not add64, sub64 to be explicit.
> I don't know if it has been proposed already, but what about a
> directive? Code could look like:
> ------
> "use precise arithmetic"; // choose any other name you'd like here
>
> var a = 0.1 + 0.2; // 0.3 // FINALLY!
> ------
> What number format should be used? I have no expertise whatsoever in
> that domain, so i'll let people who do talk.
> In his talks, Douglas Crockford mentions that the fact that JS has one
> number type is a good thing, so, maybe that choosing a unique
> replacement should be the best thing.
> Alternatively, the directive could be "parametrized" with number formats
> ("use number IEEE XYZ").
You will not get premature standardization past TC39 on this front. Our
agreement when decimal missed ES3.1 in 2008 fall (the Kona meeting) was to work
on value types so that new numeric types could be implemented in-language.
Today, that means module-encapsulated implementations, and (for usability)
value types for operator syntax. But value types as you note are not in ES6.
Sketching a directive solves *nothing*. Would Math.sin change to use the new
numeric type? If not, why not? If so, how?
Worse, what about calls from within the extent of the "use precise arithmetic"
pragma to outside of that scope? Of course we can't have dynamic scope, but
what *types* of parameters pass across the barrier? Do precise numbers coerce
with loss of precision to IEEE double?
Rather than bikeshed directive syntax, which solves nothing, we need more
design and implementation work on value types, specifically new numeric types.
Worse, we may need the "big red switch" on the side of a clique of addressable
global objects, so one can opt *everything* into the precise numeric type,
including Math, Number, canvas, WebGL, etc. And doing so may break (or at least
terribly slow down) canvas, WebGL, etc. So the big red switch may be a pipe
dream.
If so, then the problem becomes how to use different numeric types
conveniently. Per our TC39 agreement, this must mean value types, prototype
modules implementing numeric value types, user testing, and experiments with
coercion rules. This is hard, it takes time.
If we had this effort further along, we could haggle over directive syntax.
Right now, doing so is putting cart before horse.
Let's work on the hard parts first.
/be
> A directive would have the same benefits than use strict which is to not
> break existing code in platform that do not support this directive. With
> a relevant arithmetic test, feature testing will be doable, enabling to
> determine whether or not a given platform can execute accurate
> arithmetic (and taking action if not).
>
> It would also have the benefit to fix arithmetic for existing script (at
> the cost of adding a directive on top).
>
> Thoughts?
>
> David
>
> [1] http://blip.tv/jsconf/nodeconf-2011-nodecommit-panel-edited-5420208
> [2] http://blip.tv/jsconf/jsconf2011-andrew-paprocki-5455215
> [3] http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
