Separating a Hash type from Object

[Brendan Eich]

On May 30, 2007, at 9:01 AM, Jason Orendorff wrote:

> On 5/29/07, Brendan Eich <brendan at mozilla.org> wrote:
>> We're working on it. Goals and anti-goals are [...]
>
> Looks very good.
>
>> * defaults to intrinsic::=== and intrinsic::hashcode for identity and
>> hashing
>
> Perfect.
>
> There is one sort of value that isn't === itself in 3rd Edition: NaN.
> This means that hashTable.put(NaN, x) will always add a new
> entry, even if there's already a NaN entry; and the entry can't
> be retrieved!  Maybe either intrinsic::hashcode() or Hash.put()
> should detect NaN and throw an exception.

Good point -- we talked about this (it came up on python-dev too, for  
the same reason), but I forgot to note that the way  
intrinsic::hashcode is specified allows for a!==b but  
intrinsic::hashcode(a)===intrinsic::hashcode(b). So in Newton in  
April, we agreed face-to-face that all NaNs could hash to 0 (if  
memory serves). This avoids hardship computing disting codes on each  
NaN presented as input, but it doesn't help retrieval or bound table  
space.

We did not talk for long about throwing an exception for  
intrinsic::hashcode(NaN), but we certainly could do that. IIRC that's  
what Python does/will-do. Comments?

/be