Philosophical questions about collections

Lex Spoon lex at cc.gatech.edu
Fri Jul 13 06:00:18 UTC 2001




> Since abstract state is what equality depends on, it's not just a good
> definition, it's the ONLY definition.


"query" versus "modification" isn't a simple  distinction.  You can say
it depends on what the "abstract state" is, but whose abstraction shall
we use?  For example, in a Set, does it matter if #do: traverses the
elements in different orders?  In a BinaryTree, is it enough that the
same elements are present, or does the underlying tree have to be
arranged the same, too?    For my example of a button, does isPressed
count as a significant part of the abstract state?

Furthermore, why exactly does modification vs. queries matter at all? 
For example, is an OnlyOnButton different from an OnOffButton that
happens to be turned on at the moment?  If you are interested in the
steady state, then they are the same; if you are interested in the way
they behave, then they are different.



>    AFAIK, in math there isn't general #= notion except for #==; if you mean
> 	something other than #==, you need a term for the particular case. 
> 	e.g., "these two systems are homomorphic", or "these two expressions
> 	have identical normal forms".  In math, it is quite informal to say
> 	things like "these two items are equal", and it would depend on context
> 	to what is meant.
> 	
> There are, however, very clear guidelines as to what ISN'T equality.
> To be meaningful as a reading of '=', a binary predicate should be an
> equivalence predicate and satisfy
>     x1 = y1 & ... & xn = yn => f(x1, ..., xn) = f(y1, ..., yn)
> for all relevant functions and predicates f.
> 
> If you can find x and y such that x = y but not y = x, then what you have
> is definitely NOT equality.  (Hint hint.)

What counts as a "relevant" function or predicate?  Until you pick, the
mathematical test you suggest is silent.  Choosing what is "relevant"
is, in fact, precisely what the decision is about.

Overall, if you take the hard line, then you disallow #= completely, as
Bijan points out.  Someone, somewhere, might care about any selector you
name, including #==.  Thus, the only #= that will work for all possible
cases is #==.  I don't think we need to go that far, but then how do we
choose?

Here are some tries, off the top of my head.  #= should:

	1. be reflex, transitive, and, preferably, symmetric
	2. be separate from #< and #>, if those are defined
	3. be useful in a fairly common amount of code
	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




More information about the Squeak-dev mailing list