Re: CVS update: goo/src/goo/cols

[James Knight <jknight@xxxxxxxx>]

On Saturday, August 3, 2002, at 01:55  PM, Andrew Sutherland wrote:
> Perhaps the best thing here would be to maintain a consistent
> distinction between == and =, with == remaining address equality and =
> indicating semantic equivalency.  We could then construct a new
> hash-table sub-class <val-tab> (or some other equally catchy name)
> that uses = for equivalency testing.

The need for <val-tab> is completely independent of whether or not *tup* 
should override == and id-hash. (it should certainly override both, if 
either). The argument for overriding == and id-hash for tup is that it 
is an immutable type.

There is *no way* (except address-of) to determine if two pointers I 
have to a tup containing the same elements are distinct instances or 
not. Therefore, it is logically consistent to treat them as exactly 
equivalent. It would even be acceptable for the compiler to combine 
<tup>s with the same elements to be the same exact in memory object.

This is not true for most objects, e.g. <vec>, as mutating the object 
will easily show whether two <vec>s are the same object or not.

So, again, the question is whether == should be required to be a *fast* 
operation or not. My opinion is that it is more valuable to have == be 
defined as "computationally equivalent" than "fast equals". And, under 
the (currently specified!) definition, <tup> should override ==.



On the other subject, another hash method corresponding to "=" is 
absolutely necessary, and a hashtable variant that uses it should also 
exist. A method called "hash" and a subclass called "<val-tab>" sound 
like fine suggestions.

> - Put it on the to-do list to revert the == behavior for <col> and
>   <seq> to be address equivalency again.  (Perhaps go so far as to
>   make == a function (df) so that people can't do bad/stupid things.)
>   I say to-do, because I'm sure there's a hack reason that == behaves
>   like = on those classes that will break goo if changed.

Revert? "==" already is only address equivalency. "=" is defined on 
<col> and <seq>.

> - Move <str-tab> like you suggested, as its need will be obviated by
>   <val-tab> and the fact that 'hash' will be implemented on strings.

Its need won't be obviated, as the general equality function for strings 
does not (and should not) do case-insensitive comparisons, which the 
symbol table must do.

James