On Mon, Aug 15, 2011 at 8:42 PM, <[email protected]> wrote: > Send es-discuss mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: [email protected] > Subject: Re: Re: On ES.next features prototype implementations in web > browsers > Message-ID: <[email protected]> > 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 <[email protected]> > To: Brendan Eich <[email protected]> > Cc: es-discuss <[email protected]> > Subject: Re: A directive to solve the JavaScript arithmetic precision > issue > Message-ID: <[email protected]> > 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss > > > > ------------------------------ > > Message: 3 > Date: Mon, 15 Aug 2011 14:28:50 -0700 > From: Brendan Eich <[email protected]> > To: David Bruant <[email protected]> > Cc: es-discuss <[email protected]> > Subject: Re: A directive to solve the JavaScript arithmetic precision > issue > Message-ID: <[email protected]> > 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 <[email protected]> > To: Tom Van Cutsem <[email protected]> > Cc: "Mark S. Miller" <[email protected]>, > "[email protected]" <[email protected]>, > es-discuss > <[email protected]> > Subject: Re: May the defineProperty method of a proxy handler throw a > TypeError? > Message-ID: <[email protected]> > 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 <[email protected]> > To: Douglas Crockford <[email protected]> > Cc: [email protected] > Subject: Re: On ES.next features prototype implementations in web > browsers > Message-ID: <[email protected]> > 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 <[email protected]> > To: Rick Waldron <[email protected]> > Cc: es-discuss <[email protected]> > Subject: Re: A Narcissus implementation of various object literal > extensions > Message-ID: > <CAE43uqsqF03ep8o0A3TVLYzh7=Q6oFfE2634sKyQNOuSe=k...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Aug 15, 2011 at 2:58 PM, Rick Waldron <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > End of es-discuss Digest, Vol 54, Issue 29 > ****************************************** > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
