At 1:00 AM -0500 7/13/01, Lex Spoon wrote:
>
>Here are some tries, off the top of my head.  #= should:
>
>	1. be reflex, transitive, and, preferably, symmetric

These I would say rank highest. When you have these, you can use #= 
in many more ways in code than if you can't. However, I'd say 
symmetry is required and not just preferred. Otherwise you would 
always be concerned with the order of the comparison.

>	2. be separate from #< and #>, if those are defined
>	3. be useful in a fairly common amount of code

To me, this means it shouldn't be too computationally complex, to 
make it useful for iterations over your objects. Often, I find that 
the Value pattern is the easiest way to deal with this, but this just 
shifts the overhead to object creation time. In the case of 
collections, you could implement a tree in a class variable that 
represented the lattice of existing instance-values, reachable by 
element addition and sorted (by Oop?). This would work for most 
collections, but it's not cheap for the system as a whole. So I 
wouldn't recommend it for the standard library, but then the 
out-of-the-box Squeak image doesn't use collection comparison very 
often.

>	4. be no more accepting than most users will expect
>
>These criteria rely on logic, on the existing body of programs, and on
>the cognitive buildup of common users, and besides those I'm not sure my
>list is really complete.  Defining #= is pretty tough!
>
>-Lex

I omitted a lot of well spoken thoughts, because from my perspective 
it's a matter of language. There is one language called Maude 
(http://maude.csl.sri.com) which allows for multiple theories over 
the same domain, and expresses all of its terms as equations and some 
syntax constraints. I'm working on using most of it's lessons in the 
Arrow package I mentioned earlier. If it matters, Maude *has* been 
used to describe behaviors of objects and systems of objects with 
state in very interesting ways, and it does follow a long line of 
research.

I'd say that the simplest way to deal with the same in Smalltalk 
would be to work on a mechanism for multi-method dispatch in the 
cases where it makes sense, and to emulate pattern-matching of term 
types, if you really want them.

The condensed super-simple version that Smalltalk most directly 
supports is going to have semantic drawbacks that will be hard to 
explain to programmers not used to it.

FYI,
~