brendan at mozilla.com
Mon Aug 15 12:33:05 PDT 2011
On Aug 15, 2011, at 10:33 AM, David Bruant wrote:
> I have been watching JSConf talks recently and two of them  
> 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.
> 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).
>  http://blip.tv/jsconf/nodeconf-2011-nodecommit-panel-edited-5420208
>  http://blip.tv/jsconf/jsconf2011-andrew-paprocki-5455215
>  http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss