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

[James Knight <jknight@xxxxxxxx>]

> Date:	Saturday August 3, 2002 @ 1:15
> Author:	sombrero
>
> Update of /projects/dynlangs/cvsroot/goo/src/goo/cols
> In directory bongo:/home/ai2/sombrero/cvs/goo/src/goo/cols
>
> Modified Files:
> 	tab.goo
> Log Message:
> Add a id-hash variant for tup's that recursively calls id-hash on all
> elements in the tup, multiply by 31 each time and adding. (A standard
> behavior used by the java collections API when computing hashcodes
> over the contained elements.)  This has been implemented after short
> debate with Chris Armstrong, and we both agree that no one loses by
> adding this base behavior; tups are immutable, and under the current
> scheme, if you lose the reference to your tup (and this is for keys
> of course), you can't get the damn thing back out again, which is 
> stupid.

This brings up an interesting question. GOO currently has two kinds of 
equals: ==, which means "computationally equivalent", and =, which is 
the more loose "value is equal" kind of equality. The first one 
currently is defined as memory-address equality. = defaults to that, but 
is overridden in two cases -- <col> and <seq> -- to check equality based 
on the contents of the object.

So, should <tup> (or more generally, immutable objects), override == to 
do equality based on the == equality of their contents and class? This 
would be logically consistent, as they are immutable, and thus must be 
computationally equivalent (excepting the use of "address-of", which I 
assume must be excepted). However, that does have a speed overhead, and 
is not done in Java, where == *always* means compare the addresses of 
the objects. Since GOO isn't too concerned about speed, I'd say it is a 
reasonable decision.

As for this particular change:
In GOO, hashtables by default use "==" equality, not "=" equality (this 
is unlike Java, where hashtables use .equals() which is like "=" in 
GOO.). Thus, currently, I don't believe this patch will have any effect. 
If this is decided to be a good thing (tm), then == should also be 
overridden on <tup> as (note: untested):

(dm == (c1|<tup> c2|<tup> => <log>)
   (or (sup c1 c2) ;; check primitive equality first for efficiency.
     (and (== (object-class c1) (object-class c2))
       (rep eq ((e1 (enum c1)) (e2 (enum c2)))
         (if (fin? e1)
             (fin? e2)
             (and (== (now e1)  (now e2))
                  (eq (nxt e1) (nxt e2))))))))

> It's also a bit debatable why str-tab needs to be a separate class,
> although str's are mutable, so I suppose that's okay.  But it certainly
> makes sense that all immutable container objects should attempt to hash
> for equivalency.

I don't believe <str-tab> was ever intended to be a public class. It is 
(i believe) an implementation private class only for doing 
string->symbol uniquing. It should most likely be moved out of 
goo/cols/tab to goo/runtime and not be exported.

> Or something.  Feel free to revert, but I think this is a good 
> thing(tm).

James