On 9/4/14 16:00 , Chris Muller wrote:
> On Thu, Sep 4, 2014 at 2:39 PM, Andres Valloud
> <avalloud at smalltalk.comcastbiz.net> wrote:
>>>> A:  With Float nan.
>>>>
>>>>     Float nan == Float nan   "true"
>>>>
>>>>     Float nan = Float nan   "false"
>>>>
>>>> It violates what I have long considered an invariant that if a==b, then
>>>> a=b.
>>>
>>>
>>> Yep. We might want to fix that.
>>
>>
>> I'm curious now.  Where did that long considered invariant come from?  I
>
> It comes from a normal sense that an object is "equivalent" to itself.

I think the underlying issue is that "equivalent" means different things 
in different contexts.  The poor #= message, being only one, cannot cope 
with complying with multiple conflicting points of view.

> I get Eliots statement that, given all the different possible origins
> of NaN, assuming equivalency is assuming too much.  But that's a
> purists view

Well, hang on, because this comes down to one of the subtle issues we 
end dealing with all the time.  In short: we tend to reinterpret others' 
ideas to our liking.  The issue is that in doing so we might develop our 
own brand of IEEE-754 which is then incompatible with the IEEE-754 
understanding of everyone following the standard to the letter --- 
including the implementation of modern FPUs.

I'm not saying I like every single little thing in IEEE-754.  However, 
compliance gives me compatibility, portability, the ability to read 
Knuth without having to redo his work according to my private 
interpretation of IEEE-754, etc.  It's a compromise: in exchange for 
restraining oneself, one can take advantage of the work of others.

 >> also know of a real application that defined, quite on purpose,
 >>
 >> SomeDomainObject>>= anObject
 >>
 >>          ^false
 >
 > Well, I'm curious about the contexts.  What app considered an object
 > not equal to itself on purpose?

Hmmm.  I only remember the details vaguely.  It had something to do with 
a GUI display.  I also remember being shocked by what at first seemed 
like a horrible hack.  But, after spending a couple hours on it, I 
realized that accomplishing the same desired behavior in some other way 
would have been way, way more onerous.  I suspect it had to do with the 
issue of "equivalence" meaning different things at different times.

Maybe I'd look at it today and figure out something better.  At the 
time, I let that hack live.

To me, this brings back the issue that once you instantiate a class, 
it's difficult to recast the identity of the instance from a different 
point of view.  Multiple inheritance doesn't quite work.  Polymorphism 
is more practical, yet somehow incomplete.

Andres.