Support of algebraic operations on sets

nicolas cellier ncellier at
Fri Jun 15 21:18:18 UTC 2007

Blake a écrit :
> On Fri, 15 Jun 2007 10:23:56 -0700, sig <siguctua at> wrote:
>>> > Or remove them from second book.
>>> new do: [:k | book2 removeKey: k].
>> instead of:
>>   book2 difference: (book1 intersection: book2)
>> can't you see the difference?
> Hmmm. In algebra:
> 2+2*4 = 10
> In Smalltalk:
> 2+2*4 = 16
> Not to belabor the point, but Smalltalk isn't math or algebra. It does 
> have its own internal consistency ("purity", some might say), though, 
> and it's not reasonable to expect to conform to those of another 
> discipline. To my mind Smalltalk is more like, well, talking than math. 
> Which is why the above equation makes sense to me: ("Add two and two 
> together...multiply by four...."). Messages above all, right?
> Smalltalk's vocabulary has value because it is well defined and has been 
> well defined for a long time. It's not hard to create a new class that 
> does what you expect; are you suggesting that decades of code and 
> documentation be broken because this interpretation of 
> "difference"--which is exactly what I would expect if someone said, 
> "tell me the difference between this dictionary and that one"--is 
> somehow offensive to you on mathematical grounds?

Blake, I can understand your argument, Smalltalk cannot serve every 
different logics. Though they can eventually coexist with subclasses 
sometimes. Choices have to be made. Lots of ambiguity come from our 
language: different guys have differnt understandings (even math 
language is ambiguous and strongly contextual, and that's part of its 
power for sure).

But common, no math means no geometry, no windows, no menu, no Smalltalk
math/algebra is everywhere/behind/inside Smalltalk.

And enforcing the well-behaved / least surprising / strongly logical 
kernel with good mathematical background cannot be a bad thing.

I feel that's what's in the mind of sig.

Beside, most Smalltalk have Associations compared only on key. So this 
pecularity of Squeak can be argued and should have been argued. Maybe 
it's a very arbitrary choice designed for a very particular application 
without deeper thought of all implications and without consensus. Maybe 
it's a very good choice superior to other Smalltalk...
I can't say if sig point of view is right or wrong. But i can say he is 
right to open the question.

The fact that Dictionary are subclasses of Set means there are a kind of 
  Set. So its element should be unique, so Association should compare 
only on key. But in this case, Dictionary with equal keys and different 
values should be equal, something we all find... Hmm surprising...

So, making Association comparing on values seems to be a remedy to this 
surprise. But in this case, Dictionary don't behave like Set anymore... 
So the logic would be to detach them from Set hierarchy. Only the list 
of keys is a set...

Maybe we kept it there for saving a few methods duplication? But when it 
is necessary to define more methods to contradict super behaviour than 
methods we inherit, maybe it's time for a move in hierarchy. Leave your 
super and be adopted by a new family.


More information about the Squeak-dev mailing list