On 17 Feb 2011, at 10:14, Christophe Rhodes wrote:
Terje Norderhaug terje@in-progress.com writes:
I have an alternative to coming up with different names for the generic equivalent to Common Lisp functions:
Give the generic functions the same name as the equivalent Common Lisp functions and intern them in a new package that doesn't use the CL package.
Well, here's yet another alternative: trampoline the Common Lisp functions to generic functions of the same name in a new package that doesn't use Common Lisp. (This is what I have done with the sequence functions, to reasonable success).
Not that I think that a normal generic function for EQUAL/EQUALP (or whatever you want to call it) is in any way a good idea; it is a perfect example of a context-sensitive function, and modelling that with standard generic functions does not automate the inclusion of context.
Once it's a generic function, turning it into a context-sensitive function is not so hard anymore:
(defmethod equalp ((o1 my-class) (o2 my-class)) (case *my-context* (do ...) (di ...) (da ...) (otherwise ... default ...)))
...or with ContextL:
(define-layered-function my-equalp (o1 o2) (:method :in do (...) ...) (:method :in di (...) ...) (:method :in da (...) ...) (:method (...) ... default ...))
(defmethod equalp ((o1 my-class) (o2 my-class)) (my-equalp o1 o2))
The generic function equalp ensures that your own comparison methods are more easily available to other third-party code, and that's the main purpose of making it generic.
(If an existing function gets genericized, my vote would be for equalp, because I think equal still has good uses as a primitive comparison function, whereas I'm not so convinced of the utility of equalp.)
Pascal