Re: Object equality

[RLake@...]

> Actually, even before that was not the case, because "a[b]" might
> involve tag methods ;-)  So, what is the case is that rawequal(b,c)
> implies rawequal(rawget(a,b), rawget(a,c)).

I beg to differ. Regardless of the get tag method, if b and c are (object
identically) equal, then the get tag method cannot distinguish between them
and must return the same value for a[b] and a[c]. Of course, it is possible
that the tag method returns a different value each time, possibly even
ignoring one or more of its arguments. But that was not the point. With ==
defined by a tag method, even the builtin get tag method will be more
discriminating than ==, and I continue to find that unpleasant.

With respect to the question of whether type-checking is a kludge, I think
that sooner or later someone is bound to complain about it (not me) because
someone will have an application in which an element of a derived type is
in the same equivalence class as an element of a base type (complex and
real infinity spring to mind as an example). But you certainly have to do
something like what you are suggesting in order to invalidate the foo ==
nil example of "things which need object identity".