Support of algebraic operations on sets

sig siguctua at
Sat Jun 16 08:37:59 UTC 2007

On 16/06/07, nicolas cellier <ncellier at> wrote:
> 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
> >

AFAIK a pure algebra defines binary operators, but not their priority
in expressions. I'd call it a rules/conventions for writing ariphmetic
expressions rather than algebraic rules. This is the point where we
free to define own rules and still be conform with algebra.

> > 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?
> >

I'd like to see useful code which uses #difference: for dictionaries
with current semantics. I'd also would like to see this code be
portable on different smalltalk dialects and still be functional.. :)

> >
> 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.

Exactly. I don't want to explain a newcomer about Set which behaves as
not set, because "it's implemented using language specific
standards/rules". Then there's no reasons to call it a set. I think
the choice to call a set 'Set' was to make it conforming with algebra
and implementing   #union:, #intersection:, #difference: too.
Otherwise if we step further onto road of defining own standards then
why caring of defining a '+' method for numbers to return sum of two
arguments? Maybe for someone's viewpoint its better to use '*'
character for this operation? :)

> 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.

As i said before, if Association uses both key and value in
comparison, then this class have no value at all and degenerates into
array of two elements.
And dictionary degenerates to something in the middle between Set and
Dictionary is a subclass of Set, it must be more specific, while still
behave as set. But to what we see, it magically becomes less specific
by violating rules defined in parent class(es).

> 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...

I see nothing surprising in this. If we considering Association as
implication (a then b), then value doesn't involved in comparison and
two implications considered equivalent if and only if their key values
are equivalent.
>From my point of view a Dictionary is a Set, which additionally having
associated value(s) for each set element. And from this point it
cannot violate the set rules.

> 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...

No, i would like to keep a Dictionary be subclass of Set. And for
those who don't like its behaviour - implement HashedCollection or
something like that, which elements are indexed by keys, but behaving
as regular objects in comparison.

> 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.
> Nicolas

More information about the Squeak-dev mailing list