"Andrew C. Greenberg" <werdna at mucow.com> is claimed by the authorities to have written:

> Here is the crux of the argument.  In my view, the iteration is implied 
> and, moreover, is impossible to define meaningfully without using some 
> language of iteration, directly or indirectly.
I _might_ possibly agree with this part, given a charitable frame of
mind and a trailing throttle. 

> Whether the iterand is
> a receiver, parameter or the result of an expression does not, to me, 
> seem relevant.  So, too, it seems that many Smalltalk illuminati agree.
I believe I can claim to reasonably illuminated after all these years
and I really have to demurr. There are so many possible ways that code
involved in an iteration can end up messing with the order of the
elements in a collection that it's not even funny. The chief problem I
have with the argument that one should know when some code is going to
cause this problem is that it utterly smashes the nice story we so often
try to sell about encapsulation et al. If I have to know somehow that my
code is plausibly going to trigger a problem I may very well end up
having to delve into areas of the system that I don't want to worry
about, don't understand, or conceivably can't get the code for.  This
does not strike me as a good scenario.

The specific instance of removeAll: and it's close relatives is not
terrifically interesting. I'm sure we could solve it by some means
involving sticking appropriate nulls in the removed places and cleaning
up at the end of the operation, in a manner analogous to the tricks used
to save redisplayingthe Display on every little draw. Or something
equally trivial.

The general case strikes me as much more of a problem and sadly much harder
to imagine a solution for. My best guess so far is to raise a signal
when a method changes the structure and to require handling it to fix up
problems. Unfortunately it is current absurdly runtime expensive to set
up an exception handler situation and almost nobody ever bothers to use
exceptions, so I doubt this would work in practice. Conceptually it
feels like it has some merit, so perhaps some further though might be
worthwhile. 

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: IAM: Increase Amperage Above Maximum