Support of algebraic operations on sets

Ron Teitelbaum Ron at
Sat Jun 16 15:30:40 UTC 2007

> From: sig [mailto:siguctua at]
> On 16/06/07, Ron Teitelbaum <Ron at> wrote:
> > Sig,
> >
> > I'm still trying to follow this conversation, is your argument simply
> that
> > #= should be implemented in dictionary only comparing keys and not
> values,
> > so that
> >
> > (Dictionary at: #a put: 1) = (Dictionary at: #a put: 2)
> >
> > Which means that
> >
> >  | dict1 dict2 result1 result2 |
> >  dict1 := Dictionary new.
> >  dict2 := Dictionary new.
> >  dict1 at: 1 put: 5.
> >  dict2 at: 1 put: 6.
> >
> >  result1 := dict1 union: dict2.
> >  result2 := dict2 union: dict1.
> >
> > result1 = #(1->6) = result2 = #(1->5)
> >
> > and
> >
> >  result1 includes: #(1->5) = true
> >
> I think you meant:
>  #( a->b ) to be just (a->b) everywhere, because #(1->5) is the array
> with 3 elements in my squeak.. not association.

It wasn't meant to be evaluated.  I was trying to convey conceptually a
collection of associations.  Still your point is well taken.

> >  because
> >         #(1->6) = #(1->5)?
> >
> And then yes. As you can see, then everything is at right places.

Ok I see and this is where Bert's point about #do: comes in.  Since #do:
iterates over values and not keys your suggested include doesn't work.  Your
suggestion is that #do iterate over associations is so that #= can compare
keys and forget about values.

The #= message on dictionary is not a major concern for me.  Although 

Dictionary new at: #a put #b; yourself = Dictionary new at: #a put: #c;
yourself   seems odd to me, even if I do see the use in set operations.  The
set operational consistency also does not seem very useful either.
Certainly no more useful then the current implementation of #= on
Dictionary.  I would suggest that we do not change #= for the sake of set
operational consistency and would agree with Bert that Dictionaries are not

Changing #do: is a major concern for me.  There is a huge amount of value to
iteration over values and therefore we can predict a lot of people have used
it in their code.  This form of iteration makes Dictionary consistent with
Collection.  Again it is not consistent with Set operations but I don't see
the value of set operations on dictionaries since only the keys are sets.  I
don't see these relationships of keys to sets translating into dictionaries
are sets.  We expect to find only one entry per index on a dictionary, but
this is true of collections too. 

Changing Dictionary must be done extremely carefully, I would vote against
changing it to support set operations.

(I still like my suggestion of collection of values resulting from set
operations but that's me).

I don't see that this precludes you from doing what you need to do.  If we
change the superclass of Dictionary to be Collection or HashedCollection as
was suggested then you could then add your set methods implemented the way
you want them.  Maybe something like #asSetSymetricDifference: or
#asSetIncludes:  With a nice comment that says something like "The
comparisons for equality in set operations only consider keys so that the
resulting set matches algebraic rules.  For example #asSetUnion: results are
commutative using #asSetEquals.  Set operations can result in unexpected
differences in the values of your resulting dictionary since only keys are
used for set operations.  Set operations may throw out your values.  For
example ..."

Come to think of it we could just implement the set operations as
#shouldNotImplement and we can replace that functionality with the methods

Dictionaries are widely used in Smalltalk, too much so in my opinion (I'm as
guilty as anyone).  In many cases modeling your dictionary into proper
objects eliminates a shortcut but provides greater clarity to your model. 

Happy coding!

Ron Teitelbaum

> > Ron Teitelbaum
> >
> > > sig wrote:
> > > To what i propose is to be the following:
> > >
> > > SigAssociation methodsFor: 'comparision'
> > > = argv
> > >      ^ key = argv key
> > >
> > >
> >

More information about the Squeak-dev mailing list