Let me illustrate my previous post with what I did in MuO.

MuO is a framework for music composition. Any MusicalElement represent 
some sort of musical data in a temporal framework.

Two MusicalElement instances can always be mixed; the resulting mix is 
always a MusicalElement.

Here enters the concatenation/collection making ambiguity.

If a is a MusicalNote, and b another MusicalNote, then

	a,b

is a MusicalPhrase.

While if a and b are musicalPhrase, then

	a,b

is also a MusicalPhrase.

This is in the line of Chris' proposal (which I am opposed to); the 
reason I find it meaningful here is that both MusicalNote and 
MusicalPhrase are subclasses of MusicalElement.

In the context of what a MusicalElement is, it makes sense that 
concatenation of two objects leads to an object of a different class, 
similar to a collection, because both the initial objects and the 
collection are assured to mix freely via the MusicalElement protocol.

In the general case though, there is no reason that the protocol (taken 
in the broadest sense, as "expected usage") applying to object also 
applies to a collection of objects. Indeed, a collection of object is 
generally ignorant of the nature of its elements. String is an exception 
and, guess what, String does generalize concatenation to non-String objects.

Similarly, AbstractSound implements #, in a way close to Chris' 
proposal, since if a and b are sounds then a,b is a SequentialSound (the 
analog of collection in that case). But note that SequentialSound in an 
AbstractSound.

So I think we have a pattern here: Chris' proposal make sense to me when 
it operates in a delimited domain where it is clear why we can consider 
anObject to also represent {anObject}. Such a domain implicitely states 
that its objects all have a structural property of potential 
multiplicity that makes it logical that the simplest of these objects 
can be considered as composed of themselves alone.

So a Character is a sort of singleton String, seen from the point of 
view of String. Similarly, an AbstractSound is a singleton 
SequentialSound, while a MusicalNote is a singleton MusicalPhrase, as 
seen by MusicalElement.

In this way of looking to the problem, Chris's proposal makes the point 
of view of Array important enough that any Object can be seen as an 
Array singleton.

That's where I disagree, for at least two reasons:
- philosophically, I don't think Array is so central in Smalltalk that 
we have to look to every object through its eyes
- practically, we have a rich set of Collections, so why pick up Array 
other IdentitySet or SequenceableCollection ?


sorry for the long post, hope it was clear...

Stef