es-discuss Digest, Vol 54, Issue 29

John-David Dalton john.david.dalton at gmail.com
Tue Aug 16 07:11:51 PDT 2011


On Mon, Aug 15, 2011 at 8:42 PM,  <es-discuss-request at mozilla.org> wrote:
> Send es-discuss mailing list submissions to
>        es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>        es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>        es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
>
> Today's Topics:
>
>   1. Re: Re: On ES.next features prototype implementations in web
>      browsers (Douglas Crockford)
>   2. Re: A directive to solve the JavaScript arithmetic precision
>      issue (David Bruant)
>   3. Re: A directive to solve the JavaScript arithmetic precision
>      issue (Brendan Eich)
>   4. Re: May the defineProperty method of a proxy handler throw a
>      TypeError? (Cameron McCormack)
>   5. Re: On ES.next features prototype implementations in web
>      browsers (Brendan Eich)
>   6. Re: A Narcissus implementation of various object literal
>      extensions (Zachary Carter)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 15 Aug 2011 13:21:23 -0700
> From: Douglas Crockford <douglas at crockford.com>
> To: es-discuss at mozilla.org
> Subject: Re: Re: On ES.next features prototype implementations in web
>        browsers
> Message-ID: <4E497FC3.5090905 at crockford.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 11:59 AM, Brendan Eich wrote:
>> We've been extending JS in SpiderMonkey forever. Had we not, it's hard
>> to say what would have happened. One anecote: getters and setters were
>> something I added over a decade ago, such that when Firefox took
>> enough share from IE that by 2005, the live.com properties (live maps,
>> I believe) used getters and setters on Firefox to emulate IE's
>> non-standard DOM. This caused very rapid reverse-engineering of
>> getters and setters in Safari and Opera. I'm not relating this to tell
>> a story with a clean "moral". Some of this was accidental, but much of
>> it was game theory. Had we hidden getters and setters behind a flag,
>> I'm not sure what Microsoft's web developers would have done. Probably
>> use an Ajax library that did not require IE DOM quirk emulation
> I think you are probably right. They could have done a good thing, but
> getters and setters gave them a license to continue doing the bad thing.
> So ultimately they took a lot longer to finally adopt jQuery.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 15 Aug 2011 22:58:43 +0200
> From: David Bruant <david.bruant at labri.fr>
> To: Brendan Eich <brendan at mozilla.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Subject: Re: A directive to solve the JavaScript arithmetic precision
>        issue
> Message-ID: <4E498883.80109 at labri.fr>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Le 15/08/2011 21:33, Brendan Eich a ?crit :
>> On Aug 15, 2011, at 10:33 AM, David Bruant wrote:
>>> 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.
> That's an interesting piece of information. If I understand it
> correctly, it would imply that the expression "0.1+0.2" will never be
> equal to 0.3 in a JavaScript program (even with any sort of opt-in
> (@type versionning, directive, pragma...)). The best thing i can think
> of is wrapping my numbers to create values out of them. So,
> "wrap(0.1)+wrap(0.2)" can be equal to 0.3.
> (Tell me if there is a part i misunderstand or forget)
>
> Consequently, in order to have accurate arithmetic, i can:
> - wrap by hand my numbers (which doesn't scale well if i want to apply
> it to current JS files)
> - use a compiler/transpiler to wrap numbers automatically.
> But it would be hard to tell automatically which numbers should be
> wrapped and which should not. Wrapping all numbers could have annoying
> performance issues.
> - use some combining approach (interactive tool, heuristics...)
>
> Also, from what i understand, typeof( wrap(0.1)+wrap(0.2) ) could not be
> "number".
>
> A directive may not solve every problem caused by numeric types, but it
> would solve the problem of making current code work with precise
> arithmetic at a small cost (from the developer side).
>
>> 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?
> In ES5, Math.sin and most other Math functions are specified as "Returns
> an *implementation-dependent* approximation to the sine of x.", so I do
> not consider this as a concern. Regardless of underlying number
> representation, Math.sin returns a approximation of the sine of the
> argument.
>
> I guess I should return the question: how would Math.sin behave with a
> value proxy? This question stands for any in-language representation.
> Since the numeric type is defined in-language, there is not the
> "regardless of underlying numeric representation" trap that i used above
> since the representation is not /under/lying.
> Will in-language values have to define a behavior for each Math
> function? What when new Math functions are added?
> Will in-language values have to provide a "default IEEE double value" to
> work with native Math functions?
>
>> 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?
> I agree that this is an issue.
> But a first answer would be that if you really care about precision, you
> will be careful of using only precise arithmetic scripts to not be
> bothered by the dual-mode and issues that could come with it (loss of
> precision).
> If you do not care very much about precision, either you do not use the
> directive or being coerced to non-precise numbers is not an issue for
> you, so coercion sounds like a good compromise
>
>> 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
> Are there notes of the 2008 Kona meeting?
> What were the arguments leading to this agreement?
>
> David
>
>> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 15 Aug 2011 14:28:50 -0700
> From: Brendan Eich <brendan at mozilla.com>
> To: David Bruant <david.bruant at labri.fr>
> Cc: es-discuss <es-discuss at mozilla.org>
> Subject: Re: A directive to solve the JavaScript arithmetic precision
>        issue
> Message-ID: <A295BC9C-14D6-4008-8A84-029C75129088 at mozilla.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Aug 15, 2011, at 1:58 PM, David Bruant wrote:
>
>> Le 15/08/2011 21:33, Brendan Eich a ?crit :
>>> On Aug 15, 2011, at 10:33 AM, David Bruant wrote:
>>>> 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.
>> That's an interesting piece of information. If I understand it
>> correctly, it would imply that the expression "0.1+0.2" will never be
>> equal to 0.3 in a JavaScript program (even with any sort of opt-in
>> (@type versionning, directive, pragma...)).
>
> That last "even with" parenthetical does not follow from what I wrote. Clearly one could opt in via
>
>  <script type="application/ecmascript;version=decimal_nirvana_arrived">
>    alert(0.1 + 0.2);
>  </script>
>
> and have world peace, cats and dogs living together, etc.
>
> Seriously, my point was simply that TC39 will not decide on one new and more precise number type, rewrite the spec to use it (forking the old spec for compatibility with downrev scripts), and throw the "big red switch" by committee fiat.
>
>
>> The best thing i can think
>> of is wrapping my numbers to create values out of them. So,
>> "wrap(0.1)+wrap(0.2)" can be equal to 0.3.
>> (Tell me if there is a part i misunderstand or forget)
>
> No, you're overreacting still ;-).
>
> Even without a widely-scoped version selector or pragma, we want value types to support usable literals. For decimal, this means the 'm' suffix, after C# (m for "money", I'm told):
>
>    alert(0.1m + 0.2m);
>
> and of course + would work with the decimal value type's appropriate operator methods.
>
>
>> Consequently, in order to have accurate arithmetic, i can:
>> - wrap by hand my numbers (which doesn't scale well if i want to apply
>> it to current JS files)
>> - use a compiler/transpiler to wrap numbers automatically.
>> But it would be hard to tell automatically which numbers should be
>> wrapped and which should not. Wrapping all numbers could have annoying
>> performance issues.
>> - use some combining approach (interactive tool, heuristics...)
>>
>> Also, from what i understand, typeof( wrap(0.1)+wrap(0.2) ) could not be
>> "number".
>
> That's right, value types could introduce new typeof-types, e.g., "decimal", "complex", "rational".
>
>
>> A directive may not solve every problem caused by numeric types, but it
>> would solve the problem of making current code work with precise
>> arithmetic at a small cost (from the developer side).
>
> How? You didn't say anything about the runtime semantics, even if we assume a more precise floating point format (say, IEEE754r decimal).
>
>
>>> 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?
>> In ES5, Math.sin and most other Math functions are specified as "Returns
>> an *implementation-dependent* approximation to the sine of x.", so I do
>> not consider this as a concern. Regardless of underlying number
>> representation, Math.sin returns a approximation of the sine of the
>> argument.
>
> That doesn't say how the one Math.sin function object shared by scripts that |use precise arithmetic| with scripts that use IEEE double decides which representation to use: decimal or double.
>
> Also, the approximation allowed by the spec there does indeed vary among implementations, but the domain of the result is IEEE754 binary double. Not extended 80-bit binary double, not 754r decimal, not any wider format.
>
>
>> I guess I should return the question: how would Math.sin behave with a
>> value proxy?
>
> One idea that we've discussed: reverse-delegate to the argument if it is a value proxy, otherwise convert to double as today.
>
>
>> This question stands for any in-language representation.
>> Since the numeric type is defined in-language, there is not the
>> "regardless of underlying numeric representation" trap that i used above
>> since the representation is not /under/lying.
>> Will in-language values have to define a behavior for each Math
>> function?
>
> No, but they might for value types. Math.sin(x) for a value type instance x might delegate to x.reverse_sin() or equivalent.
>
>
>> What when new Math functions are added?
>
> The reverse delegation could funnel through a single method taking the name of the Math method in question, e.g. Details to be decided, but we definitely talked about this in past value types meetings, and ES4 went so far as to consider multi-methods for operators on new (value-ish) types.
>
>
>> Will in-language values have to provide a "default IEEE double value" to
>> work with native Math functions?
>
> No, that seems neither necessary nor a good idea.
>
>
>>> 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?
>> I agree that this is an issue.
>> But a first answer would be that if you really care about precision, you
>> will be careful of using only precise arithmetic scripts to not be
>> bothered by the dual-mode and issues that could come with it (loss of
>> precision).
>
> Programmers will mess this up. All the time.
>
> And it's not just about small step-wise precision differences. Decimal and double are not just imprecisely different, the different radixes result in different rounding even for common "dollars and cents" additions and subtractions. Finally, performance will differ in ways that matter, and which cannot be concealed.
>
>
>> If you do not care very much about precision, either you do not use the
>> directive or being coerced to non-precise numbers is not an issue for
>> you, so coercion sounds like a good compromise
>
> Implicit coercion in JS is one of the big remaining warts we can't easily fix in Harmony. Let's not add more.
>
>
>>> 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
>> Are there notes of the 2008 Kona meeting?
>> What were the arguments leading to this agreement?
>
> On es-discuss.
>
> https://mail.mozilla.org/pipermail/es-discuss/2008-November/thread.html#8105
>
> and look for Kona.
>
> /be
>
> ------------------------------
>
> Message: 4
> Date: Tue, 16 Aug 2011 09:42:47 +1200
> From: Cameron McCormack <cam at mcc.id.au>
> To: Tom Van Cutsem <tomvc.be at gmail.com>
> Cc: "Mark S. Miller" <erights at google.com>,
>        "public-script-coord at w3.org" <public-script-coord at w3.org>,      es-discuss
>        <es-discuss at mozilla.org>
> Subject: Re: May the defineProperty method of a proxy handler throw a
>        TypeError?
> Message-ID: <4E4992D7.8080501 at mcc.id.au>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 15/08/11 8:58 PM, Tom Van Cutsem wrote:
>> So, to future-proof if this strawman is accepted, I think it's best to
>> let existing |defineProperty| traps |return true;|.
>
> By that do you mean interpret an undefined return value as meaning
> "don't throw"?  Sounds reasonable.
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 15 Aug 2011 16:36:20 -0700
> From: Brendan Eich <brendan at mozilla.com>
> To: Douglas Crockford <douglas at crockford.com>
> Cc: es-discuss at mozilla.org
> Subject: Re: On ES.next features prototype implementations in web
>        browsers
> Message-ID: <CEEF9D11-D9B9-4E22-8D11-3D23BBC0EA1B at mozilla.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Aug 15, 2011, at 1:21 PM, Douglas Crockford wrote:
>
>> On 11:59 AM, Brendan Eich wrote:
>>> We've been extending JS in SpiderMonkey forever. Had we not, it's hard to say what would have happened. One anecote: getters and setters were something I added over a decade ago, such that when Firefox took enough share from IE that by 2005, the live.com properties (live maps, I believe) used getters and setters on Firefox to emulate IE's non-standard DOM. This caused very rapid reverse-engineering of getters and setters in Safari and Opera. I'm not relating this to tell a story with a clean "moral". Some of this was accidental, but much of it was game theory. Had we hidden getters and setters behind a flag, I'm not sure what Microsoft's web developers would have done. Probably use an Ajax library that did not require IE DOM quirk emulation
>> I think you are probably right. They could have done a good thing, but getters and setters gave them a license to continue doing the bad thing. So ultimately they took a lot longer to finally adopt jQuery.
>
> I can't tell if you're being sarcastic (ok, maybe I can :-P), but jQuery did not exist in 2005. Not until August 2006, and that would've been brand-new jQuery.
>
> /be
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 15 Aug 2011 20:42:54 -0400
> From: Zachary Carter <zack.carter at gmail.com>
> To: Rick Waldron <waldron.rick at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Subject: Re: A Narcissus implementation of various object literal
>        extensions
> Message-ID:
>        <CAE43uqsqF03ep8o0A3TVLYzh7=Q6oFfE2634sKyQNOuSe=k_oA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Aug 15, 2011 at 2:58 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
>> I've been playing with this:
>> https://github.com/zaach/reflect.js
>> which has a web interface to try out code examples here:
>> http://zaach.github.com/reflect.js/es-next/
>>
>>
>> Rick
>
> It works for simple examples but has a ways to go before it can run
> the Smalltalk Collection classes. Also, AFAICT "transpilation" won't
> be able to fully support super references (namely, rebinding super
> using Object.defineMethod)  but it can take us pretty far. The other
> features seem attainable.
>
> --
> Zach Carter
>
>
> ------------------------------
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> End of es-discuss Digest, Vol 54, Issue 29
> ******************************************
>


More information about the es-discuss mailing list