Just a quick *personal* take at answering those questions:

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
[SNIP]
> This brings me to some questions about #do: which I've been meaning to ask.
> When I ask about "general expectations", I am _not_ talking about language
> standards, and I am not talking about exceptionless rules; what I'm basically
> after is what assumptions do you make unless you think really hard about them?
> 
> 1.  Is there a general expectation that if you call #do: once, and do not
>     _yourself_ change the object you sent it to, you can do it again and
>     get the same answers, apart from their order?

Yes. At least in Collections.

>     - This is clearly violated by Stream>>do:, but do people find that
>     _surprising_, as I do?

Well, hard to say. I guess this is a case when the selector has been
reused in a similar situation without really meaning that it is meant
for polymorphism between Collections and Streams. Or? I don't find it
surprising, but I do feel that perhaps it shouldn't be called #do: in
Stream. #consume: or something perhaps. :-)

> 2.  Is there a general expectation that if you call #do: once, and do not
>     _yourself_ change the object you sent it to, you will get the same
>     answers _in the same order_ when you send it again, even for a
>     non-sequenceable collection?

Nope. non-sequeanceable to me means that I can't ever rely on any
certain order.

>     - This is violated by my NewSet class, thanks to its use of the
>     move-to-front heuristic, and it may be violated by other self-organising
>     containers.
> 
> 3.  Is there a general expectation that if you call #do:  the receiver
>     will send messages only to itself, "structural" objects that it owns
>     exclusively, and immutable objects such as numbers?

Yes. In general.

>     - This is violated by any class you have put debugging print statements
>     in, but that may be harmless.  It is certainly violated by
>     MappedCollection.  Is that surprising?  

I assume you refer to the message #at: being sent to the domain.
I would say MappedCollection and similar classes should be commented
about these things but in general I do not find this surprising.

> 4.  Is there a general expectation that if you call #do: you may safely
>     send 'query' messages to the receiver, message that do not change
>     its _abstract_ state?

Interesting. "General expectation" would probably mean a yes.
On the other hand I would think twice before doing it.

>     - This is violated by NewSet again because of its self-organising
>     nature.  You _can_ ask about the element that is currently being
>     scanned, you can even _remove_ that element, but if you _ask_ whether
>     some other element exists that may confuse the iteration.  Is that OK
>     or do I have to put a lock around move-to-front while iterations are
>     in progress and use exception handling to make sure the lock is clear
>     when all iterations are over?

Hmmm. I am not sure but I think you should secure this - it is surely a
developer trap IMHO.
But if that would somehow degrade iteration performance a lot (or
something) then perhaps you could offer a complimentary "unsafeDo:" or
something - a message that will make the developer read the method
comment (since he/she doesn't know what unsafe means) and realizes that 
"Aha, this message can be used as long as I blablabla".

> 5.  Is there a general expectation that iterating over N elements using
>     #do: is (amortized) O(N)?

General expectation yes. Surprising that it doesn't in some Collections?
No.
But then it should IMHO be in the *class comment*.

Hey guys, have you noticed that if you press the question mark in the
browser there is an area where you can actually *explain to other
developers* what a class does and what it is? Way cool! Just stumbled
over it the other day. (holding my breath, counting to ten, exhale, type
in a smiley) ;-)

>     - This is violated by the existing Set class in Squeak.  The cost
>     is proportional to the _maximum_ number of elements the Set has ever
>     had, not to the number it has right now.  Is that surprising?

Yes, the "has ever had" part was surprising indeed.

> 6.  Is there a general expectation that sending query messages to the
>     receiver during an iteration doesn't change the cost of #do:?

Yes. But see unsafeDo: above.

>     - Not true in NewSet.  Also not true in Eiffel's SET class, even
>     though it isn't self-organising.  (It has a cache, and queries can
>     invalidate the cache.)

regards, Göran