attached screenshot first.
	
My mail reader doesn't do attachments.  I treasure it for that reason.
	> Not a contradiction at all.  I wasn't suggesting *introducing* such
	> an operation, but fixing an operation that *already exists*.
	
	>>addLast:  doesn't exist for the <SortedCollection> *protocol*,
	if I've understood ANSI correctly (see below).  And the
	<SortedCollection> protocol does *not* inherit from <OrderedCollection>!

I thought we were talking about Squeak.

Squeak doesn't conform to the ANSI specification,
never has, and such conformance doesn't seem to be a goal.
One Squeaker put a LOT of work into providing some change
sets to make Squeak closer to ANSI with particular
emphasis on collection classes.  He even provided SUnit tests.

I gladly grabbed a copy of his work, and have been expecting it to
be adopted in Squeak releases.  No such luck.  It appears that
ANSI conformance is not very important to SqC.

	That is, what I've meant with introducing a not existing operation.
	
Whatever ANSI says, the operation *DOES* exist in Squeak.
In fact, a lot of code in SortedCollection depends on it, as you
no doubt found.

	> Again, RunArray>>addLast:.  
	
	RunArray isn't defined by the standard as I see it.
	
We seem to be talking at cross-purposes.
I am talking about Squeak here, and only about Squeak.
If you code in pure ANSI Smalltalk, more power to you and your
traditional UNIX-like programs (file I/O only, no sound, no GUI,
no mouse, no processes, no projects, no change sets, ...).

As a *Squeak* programmer, it is quite impossible for me to adopt
a convention that "addLast: implies OrderedCollection" because in
Squeak it isn't true.

	> I still don't have a copy of the final standard, but the 1.9 draft
	> says some funny things about SortedCollection.
	
	<...>
	
	> 	But I stay at my assumption to expect an OrderedCollection if using
	> 	>>addLast:. And if you introduce methods *** with the same name *** in other
	> 	protocols you break conventions (and ANSI is also a convention).
	> 	
	> You only break conventions if you do not follow the conventional rules
	> about refinement.  The way ANSI refines methods for SortedCollection
	> provides ample precedent for refining the *inherited* (NOT "introduced")
	> method #addLast:.
	<...>
	
	>From ANSI draft v1.9 (if you'd need it e.g. as *indexed* (very
	practical) PDF, I could send it to you):

I have the .doc file and a .txt file made from it.
If indexed PDFs search fast, that would be most kind.

	------
	5.7.17 Protocol: <SortedCollection>
	
I have seen this and know what it says.
	
	<SortedCollection> does *not* conform to <OrderedCollection> which is the
	only one defining >>addLast:.
	
Nononono.  The standard doesn't say that SortedCollection DOESN'T
conform to OrderedCollection, only that it DOESN'T HAVE TO conform.

And again, the standard defines #addLast: only for OrderedCollection,
but that doesn't mean that only OrderedCollection may have it.  A
Smalltalk implementor may provide #addLast: implementations in hundreds
of classes, if they make sense

I don't need to recite a list of other Smalltalks which also have
RunArray, do I?

	Note: here the term 'inherited' is applied to protocols, not to class
	inheritance!
	
Not terribly relevant to this discussion.  The specification only
*provides* protocols, not implementations.

The question at issue here is what one specific implementation of
SortedCollection should do in one specific implementation of Smalltalk
which is not, does not claim to be, and does not aim to be, ANSI-conformant.

	Now I've found something better: in 5.7 there is a nice graphics showing the
	conformance relationships between protocols. I've attached a screenshot.
	
	There you can see that <SortedCollection> really does *not* inherit the
	<OrderedCollection> protocol!
	
It does not say that at all.  It only says that the standard itself does
not *require* this, so that a vendor need not implement such an inheritance
and a customer may not assume it in code which is intended to be portable.

	And this is also the reason, why >>addLast: is *not* refined by
	<SortedCollection>: it doesn't need to.
	
Nobody ever said that the ANSI specification of #addLast: did or
ought to refine #addLast:.

My claim was that it DOESN'T (which you agree with)
but that there are several weird refinements of not entirely
dissimilar operations which provide *precedent* (that is,
analogies which strongly suggest how a case not previously covered
should be handled).

A particularly interesting one is
    coll copyReplaceFrom: start to: finish with: anotherColl.

For an OrderedCollection,
    oc copy addLast: x
has the same effect as
    oc copyReplaceFrom: oc size + 1 to: oc size with: {x}

If anything, this would suggest that
    sc copy addLast: x
should have the same effect as
    sc copyReplaceFrom: sc size + 1 to: sc size with: {x}
which has the same effect as
    sc add: x

This is rather strange; the stranger thing is that ANSI requires
copyReplaceFrom:to:with: to apply to SortedCollection instances
in the first place.

Now copyReplaceFrom:to:with: is in the <sequencedReadableCollection>
protocol in ANSI>.  An even closer analogue is

    n := coll size.
    coll copyReplaceFrom: n+1 to: n withObject: x

which is not in fact implemented ANYWHERE in Squeak.  So
<CSOTD>
    SequenceableCollection>>
    copyReplaceFrom: start to: stop withObject: replacementElement
	^self copyReplaceFrom: start to: stop
	      with: (Array with: replacementElement)
</CSOTD>

	Hopefully I've reduced confusion a little bit.
	
You haven't reduced any confusion about what the ANSI standard is or says.
If anything, you've created confusion in my mind.

If we're talking about the ANSI specification, there is nothing to fix.
(Not because the ANSI spec. is perfect, far from it, but because it doesn't
provide any code that could be broken.)

If we're talking about Squeak, the fact that the ANSI standard does not
*require* SortedCollection to inherit from OrderedCollection is of little
or no interest as long as the standard doesn't *forbid* such inheritance.
And for obvious historical reasons, it doesn't.

With respect to Squeak, defining a method only counts as introducing
a new method if the method was not previously defined or inherited by
the class in question.

A strict ANSI Smalltalk would be an interesting beast.  With a suitable
interpretation of file I/O, I think it should be possible to squeeze
such a system into a 32kB micro-controller.  It could be extremely useful.
But it wouldn't be Squeak.