Hi Martin and all!

Martin Wirblat <mw.projanynet at SoftHome.net> wrote:
> David Griswold wrote:
> 
> > I made a clear argument that all programs in Smalltalk (or in any
> > imperative language for that matter) have a universal, *implied* constraint
> > that you shouldn't change objects that are being used by something that
> > assumes that they remain the same.  This language-wide constraint clearly
> > excludes (x removeAll: x), and the specification for removeAll: doesn't
> > override that.
> 
> and
> 
> > Programmers should read this additional constraint into all ANSI
> > specifications, so that removeAll: has the implied language "the argument
> > can be any collection that is invariant during the execution of this
> > method".
> 
> (x removeAll: x) will NOT change x during its own execution of the part which
> relies on x being invariant, IF IMPLEMENTED PROPERLY.
> 
> => There is NO violation on principle of the mentioned language-wide constraint
> by (x removeAll: x). This differs from the iterator-methods with blocks where it
> can NOT be guaranteed for ALL possible pieces of code in the block, that this
> constraint will not be violated, whereas #removeAll: can be implemented with the
> guaranty to work correctly with ALL possible arguments.
> 
> => Therefore there is also no reason to assume that (x removeAll: x) is
> violating / has to violate this language-wide constraint. Such an assumption may
> stem from the current wrong implementation or from 'analogous' thinking of
> changing a collection while iterating over it, but it has no validity, meaning
> no programmer has to make such an assumption.
> 
> => Therefore (a removeAll: b) can and should handle perfectly well a == b
> without raising an exception, which itself has to be considered introducing a
> new error because it stops the program when the programmer has all rights to
> expect the opposite.
[SNIPPED the rest]

I agree in full with everything you wrote (including the rest) but what
is your thought on compatibility?

If Squeakers turn to rely on this code working then the code they write
will potentially not port to other Smalltalks. We could argue that
depending on how other Smalltalks do it is a weak argument that will
make any improvement in these areas impossible.

Hmmmm. Perhaps I am once again contemplating a side change here... ;-)
Yep, I feel it coming down my spine.

ANSI is unclear (haven't really read it myself) so one could, in favour
of compatibility, argue for signalling error to make sure programmers do
not use this construct. But on the other hand we already know that other
Smalltalks differ and if we choose to blindly sticking with ANSI and the
promise of compatibility then all proposed refactorings of the
Collection hierarchy goes down the tube...

And I do not like that... We should IMHO follow ANSI when there is no
reason not to, but whenever there is clearly an improvement to be made
to Squeak then we should IMHO do it.

Back on Richard's and Martin's side. I will try staying there this time.

regards, Göran