Valloud Andres <Andres.Valloud at oya.state.or.us> wrote:
	Quantify the usefulness of your expectations.

OK:  it makes the specification 50% shorter.

	Please provide real life examples where x removeAll:  x is used
	as an intention revealing feature in a dialect-independent manner.

Now *there's* a ploy!  When someone says there is a bug, demand
that he demonstrate that it already possible to use the method
across implementations without running into the bug.

Of *course* I can't do that, because there is a bug.
The only I could *possibly* provide any real life example of
x removeAll: x being used 'in a dialect-independent manner'
would be if no Smalltalk had the bug, in which case we wouldn't
be having this discussion!

With a start like that, I don't think I need to respond to anything
else in that message.  But I will.

	The standard also says the argument is to be uncaptured, which
	is defined as meaning the receiver doesn't acquire direct or
	indirect references to it.  I think the spirit of this was
	"leave the argument alone".

Well, no.  If you are going to leave the argument alone, why pass it?
If you send even one message to the argument, you are no longer in control
of whether the argument will be changed or not.

The spirit of "uncaptured" is precisely "The receiver doesn't REMEMBER
the argument afterwards."  Anything beyond that is ungrounded in the
standard and has to be justified on a case-specific basis.

	Saying "the result is undefined when argument==receiver" also
	coincides with the "leave the argument alone" attitude.
	
Except that you _can't_ leave the argument alone.  You have to send it
messages to find out what its elements are.  It is possible to construct
collections where asking the question changes the answer.  (Not very
sensible ones, granted.  But if other people may imagine hypothetical
collection classes that would break things, so may I.)

IF the argument is to be left alone, then of course it is to be left alone.
But the ANSI standard does NOT say that the argument is to be left alone.

This is actually an interesting point, which should be considered in a
future revision of the ANSI standard.  None of the #removeAll: methods
actually say _how_ the elements are to be determined.  There is no limit
whatsoever placed on which messages may be sent to the argument.

It is at least arguable that an implementation which removed the elements
from the argument one by one could conform, as long as it put them back
afterwards (if that didn't end up changing the receiver).  The standard
very carefully describes the effect on the receiver _without_ saying anything
about how it is to be done.  (Even the 'as if ... remove:' stuff doesn't
mean you have to send #remove:, because that only applies to specific
cases where the effect of #remove: is also specified.)  We really cannot
conclude from the text of the standard as we have it that no #remove:
messages may be sent to the argument.

At any rate, the standard does NOT say that #do: may be sent to the
argument or that #copy may not be.  The implementation

    aCollection copy do: [:each |
	self remove: each ifAbsent: [self errorNotFound]]

fully conforms to everything the standard says, is at least in the cases
I measured, faster than the existing implementation, and does not have the
hole in its coverage.

	The ANSI standard isn't written in stone.

No, until it is revised it is rather less mutable than that.

	I'd rather amend the standard
	than agreeing with it regardless of the cost.
	
Nobody is suggesting 'regardless of the cost'.

I have suggested many ways of getting the effect I want,
and Allen Wirfs-Brock, while pointing out that the committee
didn't think about the problem, did say that mine was a _possible_
reading of the standard.  The outcome is that in this case,
conforming to the letter of the standard, including NOT having
a hole in the domain, could give us a *FASTER* implementation
than what we have now with an interface which is *EASIER* to
understand.

It is the people who are insisting on not making this correction
who are demanding something costly, in my view.

By the way, if there _is_ a process for amending the Smalltalk
standard, I am very pleased to hear it.  Who do I write to?  What
is the process?