On Mar 2, 2011, at 14:00 , Willem Broekema wrote:

On Wed, Mar 2, 2011 at 9:44 AM, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
New version with most egregious mistakes corrected.

Thanks for the fixes on the points I raised.
I'm feeling like I miss the use case for EQUALS. The document states:

"... while writing algorithms and libraries it would be useful to have
"hooks" in the type and class system allowing for the definition of
extensible equality and comparison tests."

If an algorithm does comparison operations, then the interface should
accept a :test argument. Where does EQUALS come into play? I'm
interested in an example.

I guess the answer is: as a default to to :test argument.  Apart from that, I find using something like EQUALS allows me to avoid FUNCALL in the code, thus making it more readable.

(defun search-node (k n)
  (when n
    (if (equals k (node-key n))
        n
        (case (compare k (node-key))
             (< (search-node k (node-left n)))
             (> (search-node k (node-right n)))
             (/= (error "Cannot discriminate."))
           ))))

The example above - which can be shot down in a number of ways - may not convince you, but it is an example of code that you may want to write.

Having said that, if you want to raise that argument, then, in all fairness, EQUALS is pointless.  Yet, IMHO, that is not the point :)

Cheers
--
Marco Antoniotti