You have new collection classes?  Richard!  Why haven't you
	posted them on SqueakMap?! :-)
	
Because I wrote them as an exercise in understanding the ANSI Smalltalk
standard.  They are deliberately slightly weird.  For example, whenever
ANSI Smalltalk _allows_ a result to be a read-only sequence, I actually
return a read-only sequence.  So I have

  Object
    ListNode			(used in Sets)
      AssociationListNode	(used in Dictionaries)
    Collection
      Dictionary
        IdentityDictionary
        PluggableDictionary
      Set
        IdentitySet
        PluggableSet
      Bag
        IdentityBag
        PluggableBag
      SequenceReadableCollection
        Interval
        DateInterval		(an interval of Dates, what else?)
        ReadOnlyArray
	  Array
        ReadOnlyByteArray
	  ByteArray
        ReadOnlyString		(an array of UTF-16 codes)
	  Symbol
	  String		(adds mutation)
	SequencedContractibleCollection
	  OrderedCollection
	  SortedCollection	(note: DOESN'T inherit from OrderedCollection)

Things Squeak has that are missing:
	SequenceableCollection (basically SequenceReadableCollection)
	ArrayedCollection 
	Heap		       (I mean to put this in some time)
	LinkedList
	MappedCollection
	SharedQueue
	Text
	{Color,Float,Integer,Word}Array
	WordArrayForSegment
	RunArray
	Array2D
	SkipList and friends
	Weak{Array,IdentityKeyDictionary,KeyDictionary,Registry,Set,
		ValueDictionary}

Also, because this was an exercise in understanding the ANSI standard,
whenever the ANSI standard leaves a result unspecified, there isn't any
interesting result.  This is quite likely to break existing Squeak code.
And of course, I was trying to understand the ANSI standard, so a lot of
the Squeak methods just aren't there, mainly the standard ones, ones I
needed to implement the standard ones, and ones I couldn't resist.

Bringing this into closer conformity to Squeak would be a LOT of work.

One problem that it's hard to replace _any_ collections without replacing
_all_ collections.

Right now, for example, with #collect:into:, there are a lot of questions
that need answering.  Should WeakSet> >collect: answer a Set or a WeakSet?
Just because we don't want to hold onto the elements we started with, that
doesn't mean we don't want to hold onto the results!  I'm inclined to make
it a Set, but could that break anything?  Ditto for WeakArray.
If WeakSet> >collect: and WeakArray>>collect: return weak containers,
why do Weak*Dictionary> >collect: return plain OrderedCollections?
Why does WeakSet> >>collect: answer a WeakSet, but WeakRegistry>>collect:
answer a plain Set?  It looks to me as if all the Weak* things should
answer plain collections, not weak collections.  But would that break
anything?

Buglet:
    WeakRegistry> >printElementsOn: aStream
has
    ifNotNil: [aStream nextPutAll: '<this WeakRegistry is locked> ; space'].
which should read
    ifNotNil: [aStream nextPutAll: '<this WeakRegistry is locked>  '].


Building an ANSI-complete set of collection classes was extremely
instructive.  One thing it taught me was that I really want Traits.
I am unhappy about the amount of code that had to be copied.