[plt-scheme] equal? operator

From: Eli Barzilay (eli at barzilay.org)
Date: Mon Nov 21 16:59:51 EST 2005

On Nov 21, Hans Oesterholt-Dijkema wrote:
> Eli Barzilay schreef:
> 
> >If you need this for objects in your OO system, then why don't you
> >implement your own equality predicate using the class system?
> >(Especially given your reasons for why the standard solutions don't
> >work.)
> >
> Hmm. I don't know If I follow you here. But no, I'm not interested
> in an equal?  predicate for my OO system currently. I am interested
> in an equal?  predicate for my datastruct library (sets, avl trees,
> etc).

The equal? that you're describing is one that can be extended for new
types (you said that simply overriding `equal?' won't work), and you
don't want to simply compare all slots recursively (as you get when
using a proper inspector).  So it seems like what you realy need is a
generic equal? operation that will do the proper dispatch based on the
input type, with the ability to define new behaviors for new typs.
This sounds like something an OO system should let you do.


> >You don't want to do that!  Making `eq?' do anything else is going
> >to be confusing anyone who sees your code.
> >
> I do want to do this, because the semantics are right. Look here:
> [...]
> Now the equivalent operation in Persistent ROOS
> 
>  > (psearch (= (my-class my-attribute) 4))
> (#roos #roos #roos)
>  > (define a (car (psearch (= (my-class my-attribute) 4))))
>  > a
> #roos
>  > (define b (car (psearch (= (my-class my-attribute) 4))))
>  >b
> #roos
>  > (eq? a b)
> #f
>  > (peq? a b)
> #t
> 
> Although the memory locations of the returned roos objects are
> different, they are actually the same, in the backend system. The
> Object IDentifier of a and b adhere (= a b).

Overriding eq? is dangerous, since everyone assumes that eq? objects
are always the same pointer.  What you want is to use some other way
of identifying when an object is the same as some other object.  It
may be fine to override eq? as this new operation in your case, but in
general it doesn't work, since if you mutate one of these objects the
other does not automatically change.

One obvious solution is to use a new equality operation like you had,
but my guess is that this is not the right solution for your case.
What is more likely is that you need an extra interface layer that
`interns' values.  This is usually done by a (weak) hash table that
psearch will use -- whenever you're looking for an object, you look in
the hash table first and return the value you find, or retrieve the
actual value and store it in the table.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!


Posted on the users mailing list.