Re: Es-discuss - several decimal discussions
On Sep 3, 2008, at 11:15 PM, David-Sarah Hopwood wrote:
In the absence of decimal, Object.eq is trivial to spec:
Object.eq(NaN, NaN) = true
Object.eq( 0, -0) = false
Object.eq( -0, 0) = false
Object.eq( x, y) = (x === y), otherwise.
or to implement:
Object.eq = function (x, y) {
if (x === y) {
return x !== 0 || 1/x === 1/y;
} else {
return x !== x y !== y;
}
};
Even shorter, without else after return non-sequitur and with one
guaranteed same-type == instead of === to be perverse:
Object.eq = function (x, y) {
return (x === y) ? x !== 0 || 1/x == 1/y : x !== x y !== y;
}
But what's the point?
My point was that Decimal doesn't make the case particularly strong,
since you just need to add Decimal.compareTotal:
Object.eq = function (x, y) {
if (x instanceof Decimal y instanceof Decimal)
return Decimal.compareTotal(x, y) == 0;
return (x === y) ? x !== 0 || 1/x == 1/y : x !== x y !== y;
}
How much less trivial is this? Two lines, fewer with more ?: chaining.
Just not particularly on account of Decimal, even
with equated cohort members.
If there is a possibility that we are ever going to add decimal (or
other
types for which === might not be an identity test), then adding
Object.eq
now allows writing future-proof code for such things as memoizers --
whatever the semantics of === for decimals (or between decimals and
other numbers) turns out to be.
JS developers have to cope with downrev browsers. There's no
imperative now (ES3.1) vs. next time, since they'll need
something like the above as fallback for last time (ES3-based)
browsers.
Again my point is to avoid mission creep in 3.1. I have no problem
with identical and hashcode. If I'm wrong and they can be slipped in
without any delay, filling inevitable latency in the current
schedule, great.
I should get busy on the spec.
Ob. Bikeshed: You seem committed to eq as the name. I say it's undue
Lisp nostalgia, if not arrant cybercrud. But I concede that identical
is overlong. Alternative ideas?
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sep 4, 2008, at 12:29 AM, David-Sarah Hopwood wrote: 1. You can't do that in ES3.1 if Decimal is not in ES3.1. You'd have to add typeof Decimal !== 'undefined' to the 'if' condition. And then you'd be trying to anticipate a future spec, rather than relying on an existing one. Straw man -- Ajax library authors have to object-detect, they do it as needed. We can't predict the future, so why worry? The point is that Object.eq could be done now or later. There's no imperative to do it now, with or without Decimal. Whatever the mix of Decimal and Object.eq, library authors can and must cope -- since they'll face downrev browsers. 2. This only accounts for Decimal, not for any other future types where === might not be an identity comparison. Accounting for the future is not a reason to add an API that can be self-hosted (and will be, for older browsers). 3. It's not clear to me that this code is correct; at least not without making assumptions about how === will work on mixed arguments that have not yet been agreed. Will 1 === 1m be true (when decimals are added)? If so, then Object.eq(1, 1m) as implemented above will be true when it should be false. We haven't agreed on X, Y depends on X, therefore Y is not ready to spec -- yup, you're right. That doesn't mean we must add Object.eq now just to future-proof (even within the future that's before 3.1 is done!). Cart Horse, ahead of. The size of the code is irrelevant. Object.eq doesn't add significantly to language complexity, and provides a useful basic operation, so why shouldn't it be in the spec? Are you familiar with requirements management, scheduling? It was not the last addition that made us late. It was not the last cookie I ate that made me fat. Unless they are targetting only ES3.1-and-above. At some point (maybe several years) in the future, they'll be able to do that -- provided that Object.eq was added in ES3.1. Or we do it next time and use the self-hosted version in the mean time. You are trying to construct an absolute argument on relative terms. I could do that to add a large number of good APIs to 3.1 but then we'd be done in 2011. But if we keep arguing, we'll miss the chance to fix what's wrong in the current draft spec, so I'm going to stop here -- have the last word if you like. Not really, but eq has been used to refer to this operation for decades in both the Lisp and capability communities. I can live with Object.identical, but I'll always think of it as 'eq'. Ok. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On 2008-09-04, at 03:37EDT, Brendan Eich wrote: Not really, but eq has been used to refer to this operation for decades in both the Lisp and capability communities. I can live with Object.identical, but I'll always think of it as 'eq'. Ok. If `identical` is too long, try `id`? Or, since it is the equivalence predicate for Object/hash, maybe it should be an operator named `#=`. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 24, 2008, at 10:02 PM, Mark S. Miller wrote: Let's say you did that -- make a special case for NaN but not for -0. Let's say you use this Map to build memoize. Now let's say someone writes a purely functional function F such that F(0) is 3 and F(-0) is 7. Let's say G is memoize(F). Would you find it acceptable for G(0) to sometimes yield 3 and sometimes 7? I'd file a bug, or find a better memoizer :-). Quality of implementation eager beavers can use Math.atan2 to tell -0 from 0, just as they can use isNaN or x !== x. Yes, this is gross. I'm in favor of Object.identical and Object.hashcode, maybe even in ES3.1 (I should get my act together and help spec 'em). Just not particularly on account of Decimal, even with equated cohort members. I still agree with Sam. And as always,hard cases make bad law. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Mon, Aug 25, 2008 at 12:47 AM, Mark S. Miller [EMAIL PROTECTED] wrote: On Sun, Aug 24, 2008 at 8:09 PM, Sam Ruby [EMAIL PROTECTED] wrote: As to what the what the value of 1.0m == 1.00m should be, the amount of code and the amount of spec writing effort is the same either way. I can see arguments both ways. But if it were up to me, the tiebreaker would be what the value of typeof(1.1m) is. If number, the scale tips slightly towards the answer being false. If object, then then scale is firmly on the side of the answer being true. All things considered, I would argue for false. Typo in the above: I meant === On Sun, Aug 24, 2008 at 8:40 PM, Sam Ruby [EMAIL PROTECTED] wrote: On Sun, Aug 24, 2008 at 11:15 PM, Mark S. Miller [EMAIL PROTECTED] wrote: On Sun, Aug 24, 2008 at 8:09 PM, Sam Ruby [EMAIL PROTECTED] wrote: All things considered, I would argue for false. I'm curious. If 1.0m == 1.00m were false, what about 1.0m 1.00m and 1.0m 1.00m? 1.0m == 1.00m should be true. I'm confused. All things considered, what do you think 1.0m == 1.00m should be? true -- Cheers, --MarkM - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Mon, Aug 25, 2008 at 1:44 AM, Brendan Eich [EMAIL PROTECTED] wrote: On Aug 24, 2008, at 8:09 PM, Sam Ruby wrote: If there were an Object.eq method, then 1.1m and 1.10m should be considered different by such a function. I don't believe that decimal, by itself, justifies the addition of an Object.eq method. Even if we were to go with 1.0m == 1.00m. Good, that's my position too! Whew. Sorry for the confusion, too much after-hours replying instead of sleeping on my part. As to what the what the value of 1.0m == 1.00m should be, the amount of code and the amount of spec writing effort is the same either way. I can see arguments both ways. But if it were up to me, the tiebreaker would be what the value of typeof(1.1m) is. If number, the scale tips slightly towards the answer being false. If object, then then scale is firmly on the side of the answer being true. Ah, typeof. No good can come of making typeof 1.0m == number, but there is more room for non-singleton equivalence classes in that choice. We have -0 == 0 already. Making cohorts equivalence classes under == seems both more usable and more compatible if the operands have number type(of). If they're object then we have no precedent: o == p for two object references o and p is an identity test. In spite of this lack of precedent, I believe we are free to make 1.0m == 1.00m if typeof 1.0m == object. Note: that was a typo on my part. We agree here. But what should typeof 1.0m evaluate to, anyway? I don't believe number is right, since 0.1 == 0.1m won't be true. Is anyone seriously proposing typeof 1.0m == number? My working assumption coming out of the SF/Adobe meeting was that in ES4 there would be both a primitive decimal, which could be wrappered by the Number class, which is much in line with what you mentioned below. Based on your recent input, I now question the need to provide a decimal primitive ever. Note: here I'm talking about the conceptual model that the language exposes. Doubles are GC'ed in SpiderMonkey, as would be decimals. If Decimal is an object type, then typeof 1.0m == object is good for a couple of reasons: * Future-proof in case we do add a primitive decimal type, as ES4 proposed -- a peer of double that shares Number.prototype; typeof on a decimal would return number. See below for the possibly-bogus flip side. What would be the upside to such an approach? I can see the next-edition-of-ES-that-provides-decimal (my working assumption still is 3.1 whatever that may be called, others may be understandably skeptical) only providing a Decimal object, and with that addition the language with respect to decimal being considered a steady state that not need to be revisited in subsequent editions. * Analogous to RegExp, which has literal syntax but is an object (RegExp is worse because of mutable state; Decimal presumably would have immutable instances -- please confirm!). I'd prefer if Decimal instances in ES were considered immutable and automatically interned. By the latter, I simply mean that new Decimal(1.0) === new Decimal(1.0). Making typeof 1.0m == object could be future-hostile if we ever wanted to add a decimal primitive type, though. We're stuck if we treat literals as objects and tell that truth via typeof. We can't make them be numbers some day if they are objects in a nearer edition, with mutable prototype distinct from Number.prototype, etc. At least not in the ES4 model, which has had some non-trivial thought and RI work put into it. My assumption prior to the few days of discussion was that 1.0m was a primitive. Based on these discussions, making it be an object makes sense to me. Probably at this point, any future number types will have to be distinct object typeof-types, with magic (built-in, hardcoded) or (generic/multimethod) non-magic operator support. That may be ok after all. We never quite got the ES4 model whereby several primtiives (at one point, byte, int, uint, double, and decimal) could all be peer Object subtypes (non-nullable value types, final classes) that shared Number.prototype. We cut byte, int, and uint soon enough, but problems remained. Agreed, that may be ok after all. I can't find any changes to 11.4.3 The typeof Operator in ES3.1 drafts. Am I right to conclude that typeof 1.0m == object? Sorry if I'm beating a dead horse. Just want it to stay dead, if it is dead ;-). That was previously still on my list of things to do. Now it appears that it is one less thing to do. :-) All things considered, I would argue for false. I just wouldn't dig in my heels while doing so. I was playing down the importance of this design decision to highlight the separable and questionable addition of Object.eq, but I do think it's important to get == right for the case of both operands of Decimal type. I'm still sticking to my 1.0m == 1.00m story, while acknowledging the trade-offs. No free lunch. Again, sorry for the typo. I
Re: Es-discuss - several decimal discussions
On Sun, Aug 24, 2008 at 11:20 PM, Brendan Eich [EMAIL PROTECTED] wrote: Yes, this is gross. I'm in favor of Object.identical and Object.hashcode, I don't care if Object.eq is named Object.identical. Other than spelling, does your Object.identical differ from Object.eq? If not, then I think we're in agreement. maybe even in ES3.1 (I should get my act together and help spec 'em). Just not particularly on account of Decimal, even with equated cohort members. I still agree with Sam. And as always,hard cases make bad law. What is it you and Sam are agreeing about? I lost track. I like the point about bad law. Numerics are definitely a hard case. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eq, eql, equal [Was: Es-discuss - several decimal discussions]
On Mon, Aug 25, 2008 at 6:50 AM, P T Withington [EMAIL PROTECTED] wrote: FWIW, as a user, I've always assumed: == : equal [1] [1, 2] == [1, 2] // yields false -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Mon, Aug 25, 2008 at 9:45 AM, Mark S. Miller [EMAIL PROTECTED] wrote: On Sun, Aug 24, 2008 at 11:20 PM, Brendan Eich [EMAIL PROTECTED] wrote: Yes, this is gross. I'm in favor of Object.identical and Object.hashcode, I don't care if Object.eq is named Object.identical. Other than spelling, does your Object.identical differ from Object.eq? If not, then I think we're in agreement. maybe even in ES3.1 (I should get my act together and help spec 'em). Just not particularly on account of Decimal, even with equated cohort members. I still agree with Sam. And as always,hard cases make bad law. What is it you and Sam are agreeing about? I lost track. I like the point about bad law. Numerics are definitely a hard case. Give me a day or so, and I'll post a typo-free transcript based on running code, and people can identify specific results that they take issue with, and/or more expressions that they would like to see in the results. - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On 25 Aug 2008, at 12:29, Sam Ruby wrote: the next-edition-of-ES-that-provides-decimal (my working assumption still is 3.1 whatever that may be called, others may be understandably skeptical) Clearly that version should be called 3.1m! drj ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 25, 2008, at 4:29 AM, Sam Ruby wrote: If Decimal is an object type, then typeof 1.0m == object is good for a couple of reasons: * Future-proof in case we do add a primitive decimal type, as ES4 proposed -- a peer of double that shares Number.prototype; typeof on a decimal would return number. See below for the possibly-bogus flip side. What would be the upside to such an approach? I can see the next-edition-of-ES-that-provides-decimal (my working assumption still is 3.1 whatever that may be called, others may be understandably skeptical) only providing a Decimal object, and with that addition the language with respect to decimal being considered a steady state that not need to be revisited in subsequent editions. Yes, I was being a little too generous with the possibility of a primitive making a come-back. If we evolve by adding Decimal as an object typeof-type, that's it. Probably better this way in the long run, the operator extensions should inform our evolving thinking on generic arithmetic and multimethods. * Analogous to RegExp, which has literal syntax but is an object (RegExp is worse because of mutable state; Decimal presumably would have immutable instances -- please confirm!). I'd prefer if Decimal instances in ES were considered immutable and automatically interned. By the latter, I simply mean that new Decimal(1.0) === new Decimal(1.0). The spec should say this. Decimal.prototype would be extensible and not sealed, however, just as other standard constructor prototype objects are. A bit of a challenge in the spec, and in implementations that make an unconstructed primordial instance be the class prototype, but not insuperable (hand-wave alert). /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 25, 2008, at 6:45 AM, Mark S. Miller wrote: maybe even in ES3.1 (I should get my act together and help spec 'em). (I will help on identical/hashcode, btw -- think we're agreeing vehemently ;-).) Just not particularly on account of Decimal, even with equated cohort members. I still agree with Sam. And as always,hard cases make bad law. What is it you and Sam are agreeing about? I lost track. That if we make cohort members == and ===, telling anyone who still wants to distinguish 1.0m from 1.00m to use compareTotal is good enough. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eq, eql, equal [Was: Es-discuss - several decimal discussions]
On Aug 25, 2008, at 6:58 AM, Mark S. Miller wrote: On Mon, Aug 25, 2008 at 6:50 AM, P T Withington [EMAIL PROTECTED] wrote: FWIW, as a user, I've always assumed: == : equal [1] [1, 2] == [1, 2] // yields false This makes me sad, but some day there might be ways to attach multimethods (opt-in basis) that make it all better. Just a thought. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Mon, Aug 25, 2008 at 1:20 PM, Brendan Eich [EMAIL PROTECTED] wrote: (I will help on identical/hashcode, btw -- think we're agreeing vehemently ;-).) ;) !! On Mon, Aug 25, 2008 at 1:20 PM, Brendan Eich [EMAIL PROTECTED] wrote: On Aug 25, 2008, at 6:45 AM, Mark S. Miller wrote: What is it you and Sam are agreeing about? I lost track. That if we make cohort members == and ===, telling anyone who still wants to distinguish 1.0m from 1.00m to use compareTotal is good enough. I agree with this if-then, but why not recommend Object.identical instead? In any case, is there any general agreement about *whether* 1.0m == 1.00m or 1.0m === 1.00m? This is where I lost track. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Mon, Aug 25, 2008 at 9:45 AM, Mark S. Miller [EMAIL PROTECTED] wrote: On Sun, Aug 24, 2008 at 11:20 PM, Brendan Eich [EMAIL PROTECTED] wrote: Yes, this is gross. I'm in favor of Object.identical and Object.hashcode, I don't care if Object.eq is named Object.identical. Other than spelling, does your Object.identical differ from Object.eq? If not, then I think we're in agreement. maybe even in ES3.1 (I should get my act together and help spec 'em). Just not particularly on account of Decimal, even with equated cohort members. I still agree with Sam. And as always,hard cases make bad law. What is it you and Sam are agreeing about? I lost track. I like the point about bad law. Numerics are definitely a hard case. Here's the current output from my current branch of SpiderMonkey: js /* Hopefully, we all agree on these */ js 1.0m == 1.0m true js 1.0m == new Decimal(1.0) true js 1.0m == Decimal(1.0) true js 1.0m == 1.0.toDecimal() true js js /* And these too... */ js 1.0m == 1.00m true js 1.0m == 1.0 true js 1.0m == 1.0 true js js /* Conversion is exact, up to the number of digits you specify */ js 1.1.toDecimal() 1.100088817841970012523 js 1.1.toDecimal(2) 1.10 js 1.1m - 1.1 -8.8817841970012523E-17 js 1.1m == 1.1 false js js /* Non-strict equals doesn't care about precision */ js 1.0m == 1.0m true js 1.0m == 1.00m true js 1.0m == 1.0 true js 1.0m == 1.000 true js js /* You can mix things up */ js Decimal.add(1.1,1.1m) 2.200088817841970012523 js 1.2m - 1.1m 0.1 js 1.2m - 1.1 0.099911182158029987477 js 1.2 - 1.1 0.09987 js 1.1 1.1m true js js /* Things we agree on for strictly equals */ js 1.0m === 1.0m true js 1.0m === 1.0 false js js /* Something that a case could be made for either way */ js 1.00m === 1.0m true js js /* In any case, there always is this to fall back on */ js Decimal.compareTotal(1.0m, 1.0m) == 0 true js Decimal.compareTotal(1.00m, 1.0m) == 0 false js js /* Still open for discussion */ js typeof 1m object - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 25, 2008, at 1:59 PM, Mark S. Miller wrote: On Mon, Aug 25, 2008 at 1:20 PM, Brendan Eich [EMAIL PROTECTED] wrote: On Aug 25, 2008, at 6:45 AM, Mark S. Miller wrote: What is it you and Sam are agreeing about? I lost track. That if we make cohort members == and ===, telling anyone who still wants to distinguish 1.0m from 1.00m to use compareTotal is good enough. I agree with this if-then, but why not recommend Object.identical instead? Cuz it's more work for 3.1 than needed, and compareTotal is required by P754 IIRC. Either's good, Object.identical is better, but when in doubt... Yeah, I'm still thinking in Decimal for ES3.1 terms here. In any case, is there any general agreement about *whether* 1.0m == 1.00m or 1.0m === 1.00m? This is where I lost track. Yes, I believe Sam and I agree on those holding true. As you note, typeof x == typeof y x == y = x === y, so anything else will break that relation, and it's not just an ideal form: users, especially those taught to avoid == in favor of ===, will have our heads if 1.0m != 1.00m. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 23, 2008, at 5:45 PM, [EMAIL PROTECTED] wrote: On Sat, Aug 23, 2008 at 11:30 AM, Sam Ruby [EMAIL PROTECTED] wrote: Having Decimal.parse(2) + 3 produce 23 is not what I would call fail fast, as that is a term I would typically use for throwing an exception or the like. Point well taken. Does Maciej's followup regarding valueOf throwing solve the problem? It forces would-be Decimal users to call Decimal.add(Decimal.parse(s) + 3) (let's say s may or may not be 2 or 2). Is that a solution for ES3.1? It's user-hostile instead of future-hostile. Can we not do better, especially by not overconstraining the problem by subjecting its solution to the ES3.1 goals and schedule? Were ES designed, back in 1995, to be the language it has become, and were there time back then to have thought about how the builtin arithmetic and comparison generalizes to mixtures of decimals, arbitrary precision integers, complex numbers, matrices and polynomials, I would agree with you unequivocally. As matters stand, I'm not so sure. I've been through as many what-if's and might-have-been's as anyone. JS clearly had too much implicit magic -- Perl-envy, if you will -- to be as neatly extensible as we want, in hindsight. EIBTI, the Pythonistas say. But this need not mean explicit method calls instead of operators for any numeric extension, since that's pretty much unusable (except under SOX mandate :-/). We've often cited EIBTI in ES4 working group meetings. In general I daresay the TC39 committee is more in favor of avoiding implicit magic, especially conversions, now than ever (E4X, ECMA-357, is full of it, and it's a mess). But this doesn't mean that throwing when a Decimal is used in any not-guaranteed-to-be-numeric operand context is good. It would not be wise for equality operators, in particular, to start throwing exceptions. Could these operators simply be consistent with === for any user defined library type, and something else (a .equals() operator, say) be used to define value equality? That's incompatible, and the double-dispatched (for dyadic operators) method mapping is something we'd like to avoid in the future (wherefore multimethods). Once again, Java faced this same problem in adding BigDecimal -- and Java is strongly typed and so arguably had more leeway to add rules that make it clearer to programmers what was going on. Yet their solution was to simply create classes at the library level. BigMistake, as Cameron blogged. Java failed, C# ruled here. I think the Java analogue is instructive. In Java, primitives and objects are distinct. That's a botch, one I copied in a hurry in 1995 and regret. I should have stuck to the Self and Smalltalk sources of inspiration, but JS had to look like Java and it was easier both to implement, and to think about JS/Java bridging (LiveConnect, so-called), if I distinguished primitive string, boolean, and number from their object wrapper types. BigDecimal was apparently a clumsy enough entity that it was found to need implementation as a constructed object. This apparently backward-reasoning phenomenology is flawed. Implementors can work harder so programmers don't have to. There's no technical reason that decimal has to be a non-primitive in any language that distinguishes primitive types from first-class object types, any more than there is for strings to be non-primitive. In ES, everything is an object yet there are primitive types; this means that, when faced with a newly required constructed object type, we are tempted to slip it in as a new primitive. In the absence of extensive planning done back in the mid 1990s, I submit that the temptation is to be resisted. What extensive planning do you mean? Oh, the lack of it when I created JS. Sorry, this is bogus arguing too :-|. Five-year plans are no guarantee of success. Utopia is not an option. Lots of underused languages have over-planned designs and nevertheless have big problems (other than lack of users). Anyway, languages that do succeed in gaining users inevitably grow. Growing a language is hard but possible. Python grew, including in its numeric model and operators. In spite of harsher backward compatibility constraints, so too can JS. IEEE double is not the only conceivable number type, and indeed 32- bit int and unsigned int show through in places in JS (bitwise operators, array length). I'm not in favor of more machine types. But I think making more BigMistakes with methods only, no operators, is guaranteed to keep IEEE double the only number type that's actually used by most real-world JS programmers. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 23, 2008, at 8:23 PM, Sam Ruby wrote: The remainder of the quote that was relayed to me was that spec'ing the operators would not be hard. I took it upon myself to refamilarize myself with spider monkey and implement these operators, and despite it being a decade or so since I've done any serious C/C++ coding was able to complete that task in a long weekend. You know that I'm glad you're doing this. Doesn't mean it's going to make 3.1, or that it must. I've since started updating the spec, and the changes are very straightforward and contained. You can see for yourself, most of the changes are already in there. I will look when time permits, before the next TC39 meeting. Given this, the way I would like to proceed is towards a full and complete proposal to be ready in time for people to review for the Redmond meeting. It may very well need to be scaled back, but I would much rather be in a position where the edit requests that came out of that meeting were in the form of prune this rather than once again be presented with investigate that and report back. How would a response of take the time you need, and we'll track it for Harmony; 3.1 is otherwise all but done strike you? Frankly, it sounds like moving the goal posts. You think so? I respectfully disagree, and I've been in all the face- to-face meetings. ES3.1 started in earnest this past January, with a limit scope. Decimal (already in ES4 as proposed, with operators as well as literal syntax) was not being pushed into ES3.1 until spring- time, at which time 3.1 was supposed to be technically done in July, finalized including editorial fussing and typography in September, etc., for standardization at the December GA meeting. Seems to me the push for Decimal moved some posts. Why is Decimal-or- a-No-vote being hung like a sword over the committee's head? What goes wrong if Decimal is not in 3.1, but is (especially with user- feedback-based improvements) in the successor Harmony edition within 1-2 years? When is spec freeze? When do we need to have implementations complete? Are we planning to have these implementations usability and field tested? Will adequate time be allowed to factor in feedback that is received from these tests? Let's get the implementations done and we'll see. There's no deterministic top-down command -and-control schedule here. For the open source implementations, the main thing is to get into nightly builds, get docs and blogs educating users, gather bug reports. I'm writing the spec. I've written one implementation -- or more precisely a binding to an implementation that has been well tested and made available under a very liberal license. I've run the performance tests you asked me to run. I'm ready and willing to convert the existing decNumber test suite over to whatever format is desired; I'm also ready and willing to write additional tests to cover the ES specific binding to these functions. We should talk about landing your patch on Mozilla elsewhere. IIRC Rob Sayre asked for a few things in the bug and I haven't seen your response (I may have missed it; been busy lately). The meanings of operators when all of the operands are decimal are well specified by IEEE 754R. The meaning of equality in ES3 is a bit arcane, and we've worked through that. My SpiderMonkey implementation provides access to decNumber's compareTotal method, and Object.eq (something Doug and Mark feel is necessary for other reasons) can be defined in such a way as to make use of that function. What's the Object.eq issue? I must have missed an 8am 3.1 call. :-/ What's left is figuring out is the syntax for constructing decimals from strings (Decimal.parse sounds fine to me, how about you?), and from binary64 floating point numbers (Number.toDecimal sounds fine to me, how about you?). I like those names, FWIW. And to decide whether binary64 numbers get converted to decimal128 when they are mixed, or if it is the other way around. That is important to get right. Igor Bukanov and I both sounded off on this list as against any mixing of decimal128 and binary64 that degraded toward binary64. So I'm pleased as punch with your new thinking. I was originally pursing the latter, but based on feedback, I'm seriously considering the former -- with the proviso that the conversions be exact and correct rounded, to the limits of the precision supported by decimal128. This approach not only has the advantage of being exact and correct, it also obviate the need for use decimal. Maybe, except writing 123m all over is enough of a drag that most people won't. There still could be a case for 'use decimal'. How's the new approach (contagious decimal128) working out in the code? /be___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 24, 2008, at 12:51 AM, Maciej Stachowiak wrote: But this doesn't mean that throwing when a Decimal is used in any not-guaranteed-to-be-numeric operand context is good. Actually, throwing from valueOf would have the opposite effect. Of course, and my not- was a thinko. I meant guaranteed-to-be- numeric. Having memorized a lot of ES3, including where the preferredType hint is not number, I was not trying to make the opposite point within the same mail message. We could throw from valueOf, but at least you and I agree it would be better to avoid any such a seemingly-rushed, library-only, user- hostile Decimal. Waldemar and I said so at the Oslo meeting, and Sam agrees. I am interested to see what Sam can pull off, in code more than spec. I don't doubt the spec can be done, given design decisions from IEEE P754 and some freedom to match JS design impedance. I'm concerned we won't have time to give such a purportedly user-friendly Decimal sufficient user testing. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 24, 2008, at 6:18 AM, Sam Ruby wrote: A modest request: if the code could be reviewed and feedback provided to me with sufficient time for me to address the comments and the code to be integrated into a nightly build, by default disabled, in time for the Redmond meeting, I would appreciate it. Set the review flag to my bugzilla id -- othewise I won't see it in my request queue, and I'll probably forget to go review it on my own. Thanks. Let's posit for the moment that adding two nickles and calling toString() on the result produces 1.10 Where'd the buck come from? ;-) Ok, I'm with you so far... Furthermore assume that 1.10m 1.09m and that 1.10m 1.11m. Given the above, as well as your knowledge of ES history, what would you expect the results of evaluating the following two expressions to be: 1.10m == 1.1m true. 1.10m === 1.1m true, but there's a weak case for false if you really insist that the significance is part of the value. If we make the result be false, then people who advocate always using === instead of == to avoid implicit conversions would be giving bad advice to Decimal users. I'm sticking with true for the reason given below. Depending on your answers, there may be a followup question. Guy Steele, during ES1 standardization, pointed out that some Lisps have five equality-like operators. This helped us swallow === and !== (and keep the == operator, which is not an equivalence relation). Must we go to this well again, and with Object.eq (not an operator), all just to distinguish the significance carried along for toString purposes? Would it not be enough to let those who care force a string comparison? /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
Brendan Eich wrote: On Aug 24, 2008, at 9:34 AM, Sam Ruby wrote: What should the result of the following expressions be: 1.5m == 1.5 1.5m === 1.5 typeof(1.5m) A case could be made that both binary64 and decimal128 are both numbers, and that a conversion is required. For ==, yes. For ===, never! A case could be made that while they are both numbers, the spec needs to retain the behavior that users have come to expect that conversions are not performed for strict equality. We must not make strict equality intransitive or potentially side-effecting. Please tell me the case /should/ be made, not just could be made. And finally, a case could be made that the result of typeof(1.5m) should be something different, probably decimal, and that decimal128 values are never strictly equal to binary64 values, even when we are talking about simple integers. I'm sympathetic to the decimal128 values are never strictly equal to binary64 values part of this case, but that's largely because I am not an advocate of === over == simply because == is not an equivalence relation. == is useful, in spite of its dirtiness. Advocates of === for all use-cases, even those written by casual or naive JS programmers, are just setting those programmers up for confusion when === is too strict for the use-case at hand -- and they're setting up the TC39 committee to add three more equality-like operators so we catch up to Common Lisp :-(. The place to hold this DWIM fuzzy line is at ==. Do not degrade ==='s strictness. The typeof question should be separated. You could have typeof return number for a double or a decimal, but still keep === strict. I believe that would be strictly (heh) more likely to break existing code than changing typeof d to return object for Decimal d. If we go with object, a Decimal.parse methods won't be strictly (heh-backatcha) necessary, a Decimal constructor would do. In fact, decimal could also be called as a function. I like it when things become simpler. My only remaining comment is that might tip the scales as to whether or not 1.10m === 1.1m. They certainly are not the same object. But we previously agreed that this one could go either way. I don't see why we would add a decimal result for typeof in the absence of a primitive decimal type. That too could break code that tries to handle all cases, where the object case would do fine with a Decimal instance. IIRC no one is proposing primitive decimal for ES3.1. All we have (please correct me if I'm wrong) is the capital-D Decimal object wrapper. Guy Steele, during ES1 standardization, pointed out that some Lisps have five equality-like operators. This helped us swallow === and !== (and keep the == operator, which is not an equivalence relation). Must we go to this well again, and with Object.eq (not an operator), all just to distinguish the significance carried along for toString purposes? Would it not be enough to let those who care force a string comparison? I think that a static Decimal method (decNumber calls this compareTotal) would suffice. Others believe this needs to be generalized. I don't feel strongly on this, and am willing to go with the consensus. Premature generalization without implementation and user experience is unwarranted. What would Object.eq(NaN, NaN) do, return true? Never! Would Object.eq(-0, 0) return false? There's no purpose for this in the absence of evidence. I agree with you, compareTotal or something like it (stringization followed by ===) is enough. /be - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
First, I'd like to apologize to Sam and the other IBM folks regarding moving the goal posts. While I have repeatedly stated that I would prefer decimal not to go in at all, in recent ES3.1 phone calls it seemed we were coming close enough to closure that I expressed something along the lines of I wish we hadn't invested the time we have in decimal. But it seems like we're close enough to closure that we should just get it finished. Waiting isn't going to make this any easier. If we were as close to done as it seemed at the time, perhaps this would have been a reasonable sentiment. After Waldemar's recent posts and my reading up a bit more on decimal, I now realize I was wildly optimistic. To the degree that the exercise seems to have moved the goal posts on you, it may be largely my fault. I'm sorry for the confusion. In any case, I'm glad we seem to be in all around agreement to pull decimal completely from 3.1. This allows us to settle all remaining decimal matters in a less hurried manner. 2008/8/24 Brendan Eich [EMAIL PROTECTED]: Premature generalization without implementation and user experience is unwarranted. What would Object.eq(NaN, NaN) do, return true? Never! Object.eq(NaN, NaN) should indeed return true. Would Object.eq(-0, 0) return false? There's no purpose for this in the absence of evidence. Object.eq(-0, 0) should indeed return false. The evidence from other languages and from math itself is quite strong. I agree with you, compareTotal or something like it (stringization followed by ===) is enough. compareTotal is addressing a completely different need than Object.eq. With decimal postponed, we don't need to settle this now. But JavaScript has no well behaved *equality* operator. As http://en.wikipedia.org/wiki/Equivalence_relation explains, for a predicate P to be an equivalence relationship (and thereby to define equivalence classes), it should be * reflexive: forall x: P(x,x) * symmetric: forall x,y: P(x,y) implies P(y,x) * transitive: forall x,y,z: P(x,y) P(y,z) implies P(x,z) However, * == is not reflexive or transitive. In the Caja project, when we have occasionally violated our own style and used ==, we've always regretted it. * === is not reflexive. Fortunately, there's only one value on which it isn't, NaN, so code picking off this special case can guard uses of === which is otherwise well behaved. For code that picks off one additional special case, -0, remaining uses of === are even more well behaved. What's the definition of *equality* we all learned in grade school? Substitution of equals for equals does not change the meaning of the expression. Leaving aside -0, for all other values in JavaScript today, if x === y, then x and y and computationally indistinguishable. If you snapshot a computation, substitute some occurrences of x for y, and resume, it would make no observable difference. I expect that Harmony will have some kind of identity-map (hashtable) abstraction, and probably some kind of identity-hashcode that goes along with it. What identity comparison should these be based on? Without a guarantee of indistinguishability, you can't use such maps for transparent memoizing caches or structure-sharing low-level serialization. So today, if one wants a predicate that's both an equivalence relationship and guarantees computational indistinguishability, one can test for NaN and -0, and then use === for the remaining cases. (This is also the case for Java's ==.) But if we expect 1.0m !== 1.00m in Harmony, then this will break such code. The language itself should provide a strong equality operation that the language promises not to break in future upgrades. The most popular of Lisp's equality predicates, EQ, is indeed both an equivalence relationship and implies a guarantee of computational indistinguishability. It also has the longest history of robust use in the Lisp community. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sun, Aug 24, 2008 at 2:43 PM, Mark S. Miller [EMAIL PROTECTED] wrote: In any case, I'm glad we seem to be in all around agreement to pull decimal completely from 3.1. I believe that's a bit of an overstatement. - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
2008/8/24 Brendan Eich [EMAIL PROTECTED]: Premature generalization without implementation and user experience is unwarranted. What would Object.eq(NaN, NaN) do, return true? Never! 2008/8/24 Mark S. Miller [EMAIL PROTECTED]: Object.eq(NaN, NaN) should indeed return true. / snip / With decimal postponed, we don't need to settle this now. But JavaScript has no well behaved *equality* operator. As http://en.wikipedia.org/wiki/Equivalence_relation explains, for a predicate P to be an equivalence relationship (and thereby to define equivalence classes), it should be * reflexive: forall x: P(x,x) * symmetric: forall x,y: P(x,y) implies P(y,x) * transitive: forall x,y,z: P(x,y) P(y,z) implies P(x,z) However, * == is not reflexive or transitive. In the Caja project, when we have occasionally violated our own style and used ==, we've always regretted it. * === is not reflexive. Fortunately, there's only one value on which it isn't, NaN, so code picking off this special case can guard uses of === which is otherwise well behaved. And I'd argue that you're wrong there. NaN isn't a single value. If you did === on the object that turned into NaN when converted into a number you'd get true, because that's one specific value you're comparing to itself. But NaN represents *any arbitrary value* in the infinite set of values that cannot be converted into numbers, not a *specific value* in that set. Which means that the likelyhood of two NaNs representing the same value approaches zero and is statistically insignificant. In other words, NaN should never equal NaN using any equality operator, unless you build your number system so that NaNs remember what specific value they were converted from and do an object comparison instead of number comparison for those. Which is not the case for ECMAScript. -- David liorean Andersson ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sun, Aug 24, 2008 at 1:43 PM, liorean [EMAIL PROTECTED] wrote: And I'd argue that you're wrong there. NaN isn't a single value. Arithmetically, perhaps not. == and === already represent the arithmetic semantics of NaN and -0. Computationally, all NaNs are not observably distinguishable in ES3 and, AFAIK, in 4/4 browsers. -0 and 0 are observably distinguishable in ES3 and in 4/4 browsers. Finally, even if some NaNs are observably distinguishable from other NaNs (though this is disallowed by ES3 for EcmaScript code), that by itself doesn't justify: const x = NaN; x === x // yields false Surely x holds whatever value x holds. How can this value not be the same as itself? For an arithmetic equality primitive, I accept that this peculiar non-reflexivity may be a desirable property; or at least that this is the mistake that has become the permanent standard among numerics. However, abstractions like memoizers need to reason about computational equivalence at the level of the programming language semantics. Let's not allow the distinct needs of reasoning about arithmetic corrupt our abilities to reason reliably about computation. Object.eq(x, x) // yields true since the value of x is whatever it is. But NaN represents *any arbitrary value* in the infinite set of values that cannot be converted into numbers, not a *specific value* in that set. Then whatever set of arithmetic values is represented by the computational value in x, x is a computational value that represents that set of arithmetic values. In other words, NaN should never equal NaN using any equality operator, unless you build your number system so that NaNs remember what specific value they were converted from and do an object comparison instead of number comparison for those. Which is not the case for ECMAScript. Object.eq() is not an operator of the number system. Between two numbers, == and === are already adequate for numeric equality. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sun, Aug 24, 2008 at 7:38 PM, Sam Ruby [EMAIL PROTECTED] wrote: On Thursday, ISTR Mark arguing that correspond to the same point on the real number line was close enough to an identical test. No, I was saying the opposite! If == or === is to mean numeric equivalence, then it should say whether two numbers represent the exact same point on the real number line. I would also recommend 1.0 == 1.0m be true, though I understand (better than I did on thursday) that accurate mixed more magnitude comparison is expensive. But my main point was that, unlike binary, numeric equivalence in decimal is no longer similar to observational equivalence. If we're going to break the utility of === as an almost perfect test of observational equivalence, then we need something to take its place. This beget Object.eq. I think I need to sit down now, I'm getting dizzy. :-) Likewise ;) -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sun, Aug 24, 2008 at 7:54 PM, Brendan Eich [EMAIL PROTECTED] wrote: If === remains as good an indistinguishability test as it is now -- with only the above two exceptions -- then I'd agree we don't need Object.eq. Libraries could provide it without undue burden. However, assuming you agree that 1.0m == 1.00m, then you'd break the regularity in the first bullet. Does that not depend on what typeof 1.0m returns? Huh? As long as typeof 1.0m == typeof 1.00m, then you'd still break the first bullet. I'm trying to avoid too much creature feep in any edition ;-). Other languages have near-universally-quantified hashcode analogues but solve NaN dilemmas by throwing (Python, IIRC). FWIW, E has exactly two equality operators: * x == y implies observable equivalence, but operates more like Henry Baker's EGAL operator than like Lisp's EQ. NaN == NaN // yields true -0.0 == 0.0 // yields false * x = y means According to x, x and y are the same magnitude. NaN = NaN // yields false -0.0 = 0.0 // yields true Nice. No Decimal in E, though, with preserved significance Someone could add a decimal library to E without special dispensation from the language designers. If one did, then I'd recommend they do it such that m`1.0` == m`1.00` // yields false m`1.0` = m`1.00` // yields true (The backquote syntax is E's way of embedding DSLs. The identifier to the left of the backquote is mangled into a quasi-parser name, to parse and evaluate the string between the quotes. http://google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html brings some similar ideas to JavaScript.) It seems to me that this second way was conflated with adding Object.eq, when it's not strictly necessary to add Object.eq if those who really need to distinguish significance of two otherwise equal decimals could reach for compareTotal or stringification and == or === and cope. Object.eq isn't about numbers or strings, so that's not an adequate coping strategy. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sun, Aug 24, 2008 at 8:09 PM, Sam Ruby [EMAIL PROTECTED] wrote: All things considered, I would argue for false. I'm curious. If 1.0m == 1.00m were false, what about 1.0m 1.00m and 1.0m 1.00m? -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sun, Aug 24, 2008 at 11:15 PM, Mark S. Miller [EMAIL PROTECTED] wrote: On Sun, Aug 24, 2008 at 8:09 PM, Sam Ruby [EMAIL PROTECTED] wrote: All things considered, I would argue for false. I'm curious. If 1.0m == 1.00m were false, what about 1.0m 1.00m and 1.0m 1.00m? 1.0m == 1.00m should be true. But to answer your question, IEEE 754 does define a total ordering. One can even test is using the implementation I posted a few weeks back. js Decimal.compareTotal(1.0m, 1.00m) 1 js Decimal.compareTotal(1.00m, 1.0m) -1 This function compares two numbers using the IEEE 754 total ordering. If the lhs is less than the rhs in the total order then the number will be set to the value -1. If they are equal, then number is set to 0. If the lhs is greater than the rhs then the number will be set to the value 1. The total order differs from the numerical comparison in that: –NaN –sNaN –Infinity –finites –0 +0 +finites +Infinity +sNaN +NaN. Also, 1.000 1.0 (etc.) and NaNs are ordered by payload. -- Cheers, --MarkM - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sat, Aug 23, 2008 at 1:49 AM, Mike Cowlishaw [EMAIL PROTECTED] wrote: Finally, I'd like to take a poll: Other than people working on decimal at IBM and people on the EcmaScript committee, is there anyone on this list who thinks that decimal adds significant value to EcmaScript? If so, please speak up. Thanks. Decimal arithmetic is sufficiently important that it is already available in all the 'Really Important' languages except ES (including C, Java, Python, C#, COBOL, and many more). EcmaScript is the 'odd one out' here, and not having decimal support makes it terribly difficult to move commercial calculations to the browser for 'cloud computing' and the like. Decimals in Java are implemented at the library level, as java.math.BigDecimal. There is no expectation that intrinsic math operators work on them. Is this approach valid for ES; if not, then why not? Implementing decimals at the library level has the advantage that they can be deployed today, as functional (if slower) ES code, and optimized later on by a native implementation with no loss of compatibility. After all, it will be several years before the next ES version becomes reliably available on consumers' browsers. Does this manner of easing migration inform the approach being taken? Conversely, if one is to add support for the intrinsic math operators on decimals, does the required work generalize easily to arithmetic on complex numbers and matrices? Will the addition of complex numbers and matrices require more difficult work about how they interoperate with existing number representations (including, at that point, decimal numbers)? How, if at all, does this inform the present discussion? Ihab -- Ihab A.B. Awad, Palo Alto, CA ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sat, Aug 23, 2008 at 11:44 AM, [EMAIL PROTECTED] wrote: On Sat, Aug 23, 2008 at 1:49 AM, Mike Cowlishaw [EMAIL PROTECTED] wrote: Finally, I'd like to take a poll: Other than people working on decimal at IBM and people on the EcmaScript committee, is there anyone on this list who thinks that decimal adds significant value to EcmaScript? If so, please speak up. Thanks. Decimal arithmetic is sufficiently important that it is already available in all the 'Really Important' languages except ES (including C, Java, Python, C#, COBOL, and many more). EcmaScript is the 'odd one out' here, and not having decimal support makes it terribly difficult to move commercial calculations to the browser for 'cloud computing' and the like. Decimals in Java are implemented at the library level, as java.math.BigDecimal. There is no expectation that intrinsic math operators work on them. Is this approach valid for ES; if not, then why not? Decimal implemented as a library would be sufficient for a 3.1 release. The problem is an interoperable definition for what infix operators is required for completeness. Taking no other action, the default behavior for the result of a + operator given a Number and a library provided Decimal would be to convert both to string representations and concatenate the results. This was discussed at the last ECMA TC39 meeting in Oslo, and was found to be unusable and would create a backwards compatibility issue for Harmony. An assertion was made (reportedly by Waldemar and Brendan -- I wasn't present) that spec'ing the operators would not be all that difficult. To be sure, I then proceeded to implement such functionality using the then current SpiderMonkey (i.e. pre TraceMonkey, meaning I'm facing a significant merge -- the joys of DVCS), and found that it wasn't all that difficult. Based on the results, I've updated the 3.1 spec, and again found it wasn't all that difficult -- precisely as Waldemar and Brendan thought. At this point, I don't think the issue is infix operators. A few don't seem to like the IEEE standard (Waldemar in particular tends to use rather colorful language when referring to that spec), some have expressed vague size concerns when at this point it seems to me that we should be able to express such in measurable terms, and finally there are some usability concerns relating to mixed mode operations that we need to work through. More about this in a separate email. Implementing decimals at the library level has the advantage that they can be deployed today, as functional (if slower) ES code, and optimized later on by a native implementation with no loss of compatibility. After all, it will be several years before the next ES version becomes reliably available on consumers' browsers. Does this manner of easing migration inform the approach being taken? Conversely, if one is to add support for the intrinsic math operators on decimals, does the required work generalize easily to arithmetic on complex numbers and matrices? Will the addition of complex numbers and matrices require more difficult work about how they interoperate with existing number representations (including, at that point, decimal numbers)? How, if at all, does this inform the present discussion? Judging by other programming languages, the next form for Number that is likely to be required is arbitrary precision integers. While we can never be sure until we do the work, I do believe that Decimal will pave a path for such additions, if there is a desire by the committee to address such requirements. Ihab -- Ihab A.B. Awad, Palo Alto, CA - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sat, Aug 23, 2008 at 10:04 AM, Sam Ruby [EMAIL PROTECTED] wrote: Decimal implemented as a library would be sufficient for a 3.1 release. The problem is an interoperable definition for what infix operators is required for completeness. Taking no other action, the default behavior for the result of a + operator given a Number and a library provided Decimal would be to convert both to string representations and concatenate the results. In other words, the same as the + operator given a Number and a library provided Employee, Document, PopupWidget, ..., or any other user defined type. This was discussed at the last ECMA TC39 meeting in Oslo, and was found to be unusable and would create a backwards compatibility issue for Harmony. With respect, I wonder what these would be. It seems that the fail-fast behavior in this case is useful for (as I pointed out) stuff like helping establish Sarbanes-Oxley compliance. I understand that such requirements are why we need decimal arithmetic in the first place. ... spec'ing the operators would not be all that difficult. ... there are some usability concerns relating to mixed mode operations that we need to work through. It is precisely these concerns that cause me to wonder if there's a foundational issue here. Are decimals indeed a different enough beast, and the pitfalls subtle enough (even if they can be specified completely), that mixed mode should simply not be supported (i.e., made to fail-fast in some backwards compatible way)? And if mixed mode is not supported, does that mean the library approach is adequate? Ihab -- Ihab A.B. Awad, Palo Alto, CA ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
Sam Ruby wrote: [EMAIL PROTECTED] wrote: In other words, the same as the + operator given a Number and a library provided Employee, Document, PopupWidget, ..., or any other user defined type. Having Decimal.parse(2) + 3 produce 23 is not what I would call fail fast, as that is a term I would typically use for throwing an exception or the like. Would the following trick make mixed mode unnecessary? Say your program uses Decimal, but imports several old libraries that know nothing about Decimal. Say you tell the compiler to compile these old libraries in an all-Decimal mode. You just force them into Decimal, ignoring the fact that they were written for binary. If /everything/ becomes Decimal, the whole language, is it likely that the libraries will have a problem with this? Isn't it extremely likely that they will just work perfectly? I've mentioned this before, but I'm not sure if I was clear and understandable. Forgive me if I'm repeating something that isn't useful. As a naive onlooker I think this /sounds/ simple. -- Ingvar von Schoultz ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 23, 2008, at 11:30 AM, Sam Ruby wrote: [EMAIL PROTECTED] wrote: On Sat, Aug 23, 2008 at 10:04 AM, Sam Ruby [EMAIL PROTECTED] wrote: Decimal implemented as a library would be sufficient for a 3.1 release. The problem is an interoperable definition for what infix operators is required for completeness. Taking no other action, the default behavior for the result of a + operator given a Number and a library provided Decimal would be to convert both to string representations and concatenate the results. In other words, the same as the + operator given a Number and a library provided Employee, Document, PopupWidget, ..., or any other user defined type. Having Decimal.parse(2) + 3 produce 23 is not what I would call fail fast, as that is a term I would typically use for throwing an exception or the like. One possible way to achieve fail fast in a library only solution would be to specify that Decimal.prototype.valueOf always throws an exception. This would make an attempt to add or multiply using the operator throw, but would still allow decimal numbers to be printed, and would allow for explicit conversion methods. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Sat, Aug 23, 2008 at 11:30 AM, Sam Ruby [EMAIL PROTECTED] wrote: Having Decimal.parse(2) + 3 produce 23 is not what I would call fail fast, as that is a term I would typically use for throwing an exception or the like. Point well taken. Does Maciej's followup regarding valueOf throwing solve the problem? At most, Sarbanes-Oxley might be an example of one source for requirements. It's even weaker than that -- my suspicion (admittedly in ignorance) is that SOX does not inform us directly regarding interoperation of numerics in ES or elsewhere. :) Yet as a programmer, I would feel much better if I know that my carefully controlled arithmetic automatically checks for the silly mistakes I could make (especially under ES's dynamic typing). Removing problematic implicit conversions and comparisons with native numerics could be one way to achieve that. I don't believe the concerns are that decimals are a same enough or a different enough beast, but rather that fail fast is not the type of behavior one would expect from ES for numeric operations. Were ES designed, back in 1995, to be the language it has become, and were there time back then to have thought about how the builtin arithmetic and comparison generalizes to mixtures of decimals, arbitrary precision integers, complex numbers, matrices and polynomials, I would agree with you unequivocally. As matters stand, I'm not so sure. It would not be wise for equality operators, in particular, to start throwing exceptions. Could these operators simply be consistent with === for any user defined library type, and something else (a .equals() operator, say) be used to define value equality? Once again, Java faced this same problem in adding BigDecimal -- and Java is strongly typed and so arguably had more leeway to add rules that make it clearer to programmers what was going on. Yet their solution was to simply create classes at the library level. I think the Java analogue is instructive. In Java, primitives and objects are distinct. BigDecimal was apparently a clumsy enough entity that it was found to need implementation as a constructed object. In ES, everything is an object yet there are primitive types; this means that, when faced with a newly required constructed object type, we are tempted to slip it in as a new primitive. In the absence of extensive planning done back in the mid 1990s, I submit that the temptation is to be resisted. Ihab -- Ihab A.B. Awad, Palo Alto, CA ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On Aug 23, 2008, at 8:44 AM, [EMAIL PROTECTED] wrote: On Sat, Aug 23, 2008 at 1:49 AM, Mike Cowlishaw [EMAIL PROTECTED] wrote: Finally, I'd like to take a poll: Other than people working on decimal at IBM and people on the EcmaScript committee, is there anyone on this list who thinks that decimal adds significant value to EcmaScript? If so, please speak up. Thanks. Decimal arithmetic is sufficiently important that it is already available in all the 'Really Important' languages except ES (including C, Java, Python, C#, COBOL, and many more). EcmaScript is the 'odd one out' here, and not having decimal support makes it terribly difficult to move commercial calculations to the browser for 'cloud computing' and the like. Decimals in Java are implemented at the library level, as java.math.BigDecimal. There is no expectation that intrinsic math operators work on them. Is this approach valid for ES; if not, then why not? See http://jroller.com/cpurdy/entry/the_seven_habits_of_highly1 (especially the first comment, by Bob McWhirter) also see https://bugzilla.mozilla.org/show_bug.cgi?id=5856 All linked from the still-useful http://wiki.ecmascript.org/doku.php?id=discussion:decimal Implementing decimals at the library level has the advantage that they can be deployed today, as functional (if slower) ES code, and optimized later on by a native implementation with no loss of compatibility. http://gwt-math.googlecode.com/svn/trunk/gwt-math/src/main/resources/ com/googlecode/gwt/math/public/js/bigdecimal.js ;-) After all, it will be several years before the next ES version becomes reliably available on consumers' browsers. Several years or less than a year from final spec, depending on the vendor's commitments to standards. Does this manner of easing migration inform the approach being taken? Not really. If you want GWT, use it. If you want a library, they are out there. The problem is making a new type in ES3.1's spec work, both now and in the future when operators are added (so we can avoid the laughable but totally predictable outcome Bob McWhirter cited in Purdy's blog). Conversely, if one is to add support for the intrinsic math operators on decimals, does the required work generalize easily to arithmetic on complex numbers and matrices? We might hope to know by looking at other languages, but really, doing the work in the context of backward JS compatibility is required. So again, doing what Sam is doing in developing patches against open source JS implementations seems at least as valuable as trying to spec Decimal quickly, making it law, and then hoping it works out in the future *and* somehow leads to a taller numeric tower. Will the addition of complex numbers and matrices require more difficult work about how they interoperate with existing number representations (including, at that point, decimal numbers)? How, if at all, does this inform the present discussion? You might find http://wiki.ecmascript.org/doku.php?id=proposals:generic_functions interesting. Obviously not a live proposal, but if we ever want operators, I'm still in favor of multimethods instead of hardcoding. The current untestable spec can't stand much more complexity in its runtime semantics. If we ever get complex numbers, quaternions, etc., they should come by users defining operator multimethods after the committee has retired in victory to the same Valhalla where Dylan and Cecil are spoken :-/. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
