sql.mawi at t-link.de
Tue Jun 15 08:29:09 UTC 2004
"Richard A. O'Keefe" wrote:
>Remember the fundamental rule about #hash:
> x = y implies: x hash = y hash
>Now, suppose we have two different Set objects x, y, which have the
> x := #(1 2 3 4) asSet.
> y := #(3 1 4 2 4 1 3) asSet.
>We expect that x = y. After all, two sets are equal if and only if
>they have equal elements, and if Sets don't act like sets, they have
>no right to the name. If we *ever* hope to use Sets as elements of
>other Sets or as keys in a Dictionary, they had *better* get equality
I guess you are referring with "the name" to how mathematicians have
defined their Sets. They have platonic Sets, meaning = and == are not
distinguished. Here on earth representation or materialization
matters, so programmers can have different sets with the same contents.
Programmers' Sets are different from mathematicians'. A mathematician
can't add something to a set without getting another set. After
adding something to a set a programmer has of course the same object
and that may lead him to think that he has the same set.
> For me it is totally nonintuitive not to be able
> to put any Set into another one.
>No, you've got it wrong. What I said was that you cannot put a Set
>object inside ITSELF. You can put a Set inside a DIFFERENT set with
>no trouble at all. In fact, from what you have said, out of Ambrai,
>Dolphin, VSE, VW, and Squeak, Squeak is the *only* one where you *can*
>usefully put a Set inside another Set.
I know what you said. But you are implying that a set is the Set of
the mathematicians. Only then you can put a set into another set. Such
a Set must not be changed, which contradicts to the programmer's day
to day use of Set.
> In fact every object that is explicitly designed to change its
> contents but which is not maintaining its hash value will give
> the programmer no intuitive clue that it can't be put in a Set.
>I am always suspicious of appeals to 'intuition'. One can reasonably
>expect a Smalltalk programmer to know the two fundamental rules of
>(1) x = y implies: x hash = y hash
>(2) A mutable object should not be mutated while its hash value is
> that is, while it is a member of a set or bag or a key in a
That may be clear to you, but I bet that many if not most people who
are programming Smalltalk (i.e. including many newcomers) are not
aware of this problem, which is pretty good demonstrated by the fact
that different Smalltalk dialects implement Sets differently (and only
Squeak gets it right in your opinion).
After all one criterion for the quality of a programming language is
how intuitive it is. A Set and even more a Bag is a brown sack for me.
I stuff things in it and from time to time I ask if something specific
is in it. I would be astonished when I order to put something new into
the sack and it vanishes from the cellar of my warehouse and pops up
in the loft.
Arrays and Strings can be created literally and can not change size.
There is a difference to Sets and that's what I wanted to express with
"explicitly designed to change". Arrays and Strings are more alike the
mathematician's Set than the programmer's Set is.
A Squeak Set implements the mathematician's equality for #=. My brown
sack would be better suited with implementing identity for #= and
#hash accordingly and an additional #equals: would serve the
mathematicians. Perhaps the question is, if the average programmer is
more a mathematician or a warehouse worker?
More information about the Squeak-dev