Stephan Rudlof <sr at evolgo.de> replied:
	> (I had to get a technician to show me how to turn my
	> new eMac back on again.  This was rather humiliating.)
	
	What about simply switching it off and then on? ;-)
	
Turning it off (<Apple>|Shutdown) was not a problem.
What I said was that *turning it back on* was a problem.
There is no visible power switch on an eMac.
Apparently, having a "turn it on key" on the keyboard the way
they used to would mean the USB bus draining power all the time,
even when the machine is "switched off".  So they put the "turn
it on button" on the front of the box, right?  Nope.  Oh, there's
a panel on the front you can pull down, it's there, right?  Nope.
It's up against a wall, so it's hard to *look* around, so have a
good *feel* all around the box for something sticking out.  Nope,
nothing there either.  Turns out the "turn-it-on button" is on
the right side, hidden behind a bunch of cables, and flush with
the surface so you don't have to notice it.  Not only is it flush
with the surface, it's even the same colour.

User interface issues matter a lot, and industrial design artists's
desire to produce a cool looking box should NOT be the last word.

	>     |s|
	>     s := Set new.
	>     1 to: 10 do: [:i| |a|
	>       a := Array with: i with: nil.
	>       a at: 2 put: a.
	>       s add: a].
	> 
	> Here we have a case where x = y is going to terminate quickly, but
	> x hash will not terminate and neither will y hash.
	
	I'm not able to follow you here:

The "x" and "y" in question are the _elements_ we are trying to add
to the set.

	> Even without cyclic structures, a depth-bounded hash can be useful
	> because it reduces the amount of work done for large trees.
	
	Agreed.
	
I should confess that I thought of depth-bounded hashing years ago
for Quintus Prolog, where the problem was that a term may only be
partially known.  Typically there would be some level of structure
which was enough to ensure that the terms in a collection were
distinct, but parts of the terms were not yet known.  Functional
programmers will have heard of "promises" and "futures"; promises are
where a computation has been delayed until the result is first needed,
and futures are where a computation is being done in another thread and
will be delivered when available (and if you need the result before
that you'll be suspended).  Promises and futures have been used in
object-oriented programming as well.  A Promise object, for example,
could respond to any message by evaluating a block, becoming the result,
and resending the message.  So a depth-bounded hash could be useful in
that case.

	>     This isn't surprising.  The original Smalltalk-80 used reference
	>     counting, so you really were NOT supposed to have cyclic objects at
	>     all anyway.  Trying to put a Set inside itself would have been a big
	>     No-NO on garbage collection grounds.
	
	Actually I think we have root objects: therefore this part of the
	problem should be a NOP (no problem).
	
Root objects have nothing to do with it.  The problem is that straightforward
reference counting cannot ever reclaim objects that are in cycles.  (That's
part of what the initialise/release stuff was about; MVC programs might
involve cycles temporarily, but you had to be very careful to break all
the relevant cycles when a window was closed.)

	> (b) We could change Squeak so that it does handle #hash and #= for
	>     cyclic objects.  That would be a lot of work,
	
	Are you sure that it is that much work?
	
Put it this way, doing this in a completely new implementation of an OO
language would not be too hard.  But getting the entire Squeak community
to switch over to a more complicated and slower version of #= and #hash
to cope with a problem most of them avoid anyway would require a lot of
work by a lot of people.

	Nevertheless it's important to keep in mind that even with these changes
	 a programmer shouldn't change an Object inside a hashed container...
	
Indeed.

	>     In the case of such a cyclic graph of objects, the default implementations
	>     of #= and #hash inherited from Object may be just right.  I don't mean
	>     just "pragmatically useful", I mean "correct".  In such a case the object
	>     identity often really is part of what it represents.
	
	I have to put some water into the wine here: it depends.

Note again that little word "MAY" in "may be just right."

	Imagine a graph stored serialized into some file and now you want to
	compare the stored graph with incidentally the same one kept in memory
	after filing the stored one in again...
	
Graph isomorphism is sufficiently hard that it has a complexity class
named after it.  There are some fast algorithms, but "fast" is a relative
term, and a thousand nodes counts as "very large" still.  If I wanted to
do something like this, I would try to restrict the class of graphs and
the serialised representation so that there was a canonical form.

But all of this is precisely why #= is user-definable.