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 =
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.
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
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).
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
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
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
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,
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
___
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
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
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
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,
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
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
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
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
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
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 ==,
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
34 matches
Mail list logo
