Hi,

> This would make sense for sets of immutable objects.  Presumably, it 
> makes no sense to create sets of mutable objects, but there is no way 
> to enforce that restriction.

  You're right.  My proposal doesn't make sense ^^;

> Once Sets store the hash, they could also keep the elements in hash 
> order, and do binary search rather than linear search.

> I imagine that Yoshiki's original comment "but it requires VM 
> modification" to allude to the fact that Set is a superclass of 
> MethodDictionary, and methodDictionarys are "known" to the VM.
> Where does it say how much is known?  Are Sets themselves
> "known"

  Yes, this (methodDict is known to the VM) is what I wanted
to say.  But I found I don't know the actual reason why the
VM crashes (yeah, it crashes) when I add an inst var to Set
(put new one after existing two).  The VM knows the index of
'array' inst var (MethodArrayIndex), but adding new one
doesn't change it.

  My best guess is that because the replacement of the old
class to new class (in ClassBuilder) isn't 'atomic', it
means it involves several method lookup during mutating
MethodDictionary instances, so the method lookup fails in
subtle way at somewhere.

  -- Yoshiki

P.S.
  By the way, when a SIOUX window appears (I'm talking about
the Mac VM), what am I supposed to do?  I can't recall what
I did exactly at the last time it appeared, but I couldn't
close/kill/quit the white blank window remaining and
eventually I had to turn-off the the machine.  (I don't want
to try to figure out it by myself:-)