> Eh?  You think BUG-compatibility is important?
	> Look, StarMorph new openInWorld _also_ doesn't work in VisualWorks;
	> does that mean we shouldn't let it work in Squeak?
	
	1) The argument presupposes the conclusion that the behavior is a bug; 
	many have argued persuasively that it is not; and
	
The argument does not presuppose that conclusion.
The argument is the continuation of several days more or less continuous
typing arguing *in detail* and with reasons that is a bug.  I think I am
allowed to be consistent with myself.

	2) Compatibility *is* a very important, albeit not overriding, 
	consideration.  We don't want to break programs between versions.
	
Yeah, but you CAN'T be compatible with BOTH VW *and* IBM Smalltalk on
this point.  Because VW gets it wrong, and IBM Smalltalk gets it right.
(At least in the case of OrderedCollections.)

When you can't be compatible with everyone, why not be compatible with
the one that works in more cases?

	> 	Introducing an assertion, which makes the implicit precondition 
	> explicit
	> 	though, doesn't hurt compatibility.
	> 	
	> Yes it does.  If (coll removeAll: coll) quietly succeeds in VW
	> but reports an error in Squeak, that is even *less* compatible than
	> making it produce the right answer.
	
	As at least one of the co-authors of the Smalltalk ANSI standard has 
	already written in these letters, this is acceptable precisely because 
	the case was not intended to be defined as you have argued, 

You've lost me.
    "We forgot to think about that"
does NOT imply
    "This is acceptable".
That just isn't how you read standards.
You read standards AS THEY ARE.

	notwithstanding the interpretation you impose on the words.

I haven't imposed anything on the words.  I have let them speak for
themselves.  That's how you read a standard.

	As an undefined result, any behavior conforms to an undefined
	case

But it *ISN'T* an undefined result.  The return value is explicitly
specified, but the effect on the receiver is clearly spelled out.
It is the people who want to argue that there is some case in which
the required behaviour need not be produced who have to find some
explicit warrant for the exception.

I don't see how anyone reading the ANSI text would dream of there being
an exceptional case UNLESS they had read the implementation in Squeak
first and thought that was more authoritative than the text of the
standard.

Even then, I have now shown that a small efficiency tweak to
#removeIndex: in OrderedCollection will make the code *as it stands*
produce the correct behaviour for OrderedCollection.  The fact that
the actual code of removeAll: *as it stands* can deliver the right
answer when #removeindex: is changed in a way that does not in the
least change compatibility with ANSI, comments, books, programmers'
expectations, or any other outwardly visible behaviour, makes the
claim that the bug is somehow allowed or required by the ANSI specification
look very weak indeed.  The bug is basically caused by the fact that
#removeIndex: does on average twice as many moves as it needs to.
When a bug results from an inefficiency in a private method,
it is ridiculous to claim that it's somehow "right".

If someone had added a new primitive resembling C's memmove() and
made #removeIndex: call that instead of the one it does call
(which more closely resembles memcpy()), purely in the interests of
efficiency, the bug would have gone away (in the case of OrderedCollection)
and we might never have known it was there.

	This is why David's proposal (trap as an error, by assertion or 
	otherwise) seems to be the best heard to date thus far.
	
Actually, I proposed it first.