Tim, you're apparently not reading my posts very carefully because
everything you're responding to are things I specifically dealt with.

I didn't say that collections should be copied before iterating over them.
I specifically said that such copies are too expensive.

I didn't say that collections should be locked while iterating over them, I
only said that it doesn't make sense to expect iterators to change their
behavior mid-stream if you try to mutate collection out from under them -
that this was too much to ask, just like implicit copying was too much to
ask.

I didn't say that I wanted arrays locked in a specific memory location while
iterating over them, I specifically said that allowing the GC to move them
was not onerous as long as there's some way for Slang code to keep track of
where the array is.

As for being lectured about how I don't know enough about garbage
collectors.  Well that would be true if I had said any of what you assumed I
was saying...  Actually I know enough about GCs.

Is my writing that hard to understand?

I'd respond to what you said about become: inside of iterators, but I'm not
getting the impression that you read what I said about become: any more
carefully than you read what I said about iterator primitives.  You
certainly didn't respond to a single idea I stated...

Ah well, I try anyway:
Here's a new idea about "become:"  "become:" has such drastic effects that
no method can run properly if it's owner is changed by "become:" unless it
was designed or vetted for that specific change.  No iterator in Squeak was
designed to handle it's object being changed out from under it - so they
will exhibit various bugs - bugs that would be different if trivial
internals of those method were changed slightly - arbitrary bugs.  Your
example tells me nothing about become: becaue it isn't proper useage of
become:.

As for multitasking examples - that's something else a program has to be
specifically designed to handle in all of it's parts... Once again, the
iterators weren't designed to have their objects changed out from under them
by multithreaded programs - so they don't handle it in any reasonable way,
and will exhibit bugs.

If you want to propose redesigns of every iterator to handle these things go
ahead.  BUT IT'S NOT A FLAW IN MY PROPOSAL THAT IT DOESN'T MAKE THE CODE
HANDLE CASES THAT IT ALREADY CAN'T HANDLE.

Joshua Scholar