Finding the applicable methods...
"David McClain (as dbm at refined-audiometrics dot com)" <[email protected]> Mon, 13 Jul 2026 15:54:38 -0700
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_5B62876B-8D25-4708-83EF-BDA32453AD96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Sorry if this opens up a can of worms=E2=80=A6 For more than 30 years, I =
have been a happy Lisper without actually ever needing to find the list =
of applicable methods for a generic function being applied to specific =
arguments. The LW CLOS system just performed in the manner I glibly =
expected.
But now, I am trying to define a generalized 3-way comparison operation =
against pairs of objects (like a Fortran-IV IF statement). And I have a =
few :AROUND methods, as well as a ton of possibly intersecting direct =
methods against various pairs of argument types.
And so now, looking up how to find which methods will be called - =
CLOS:COMPUTE-APPLICABLE-METHODS. Actually the MOP spec states that =
CLOS:COMPUTE-APPLICABLE-METHODS-USING-CLASSES would be called first, and =
then the former would be called only if the -USING-CLASSES returns a =
false second value.
But LW does not seem to have this =
COMPUTE-APPLICABLE-METHODS-USING-CLASSES. And CLOSER-MOP also claims to =
not have such a method, when I hand it an LW:STANDARD-GENERIC-FUNCTION. =
But it does seem to have it for a CLOSER-MOP:STANDARD-GENERIC-FUNCTION. =
(I guess I should learn how to make a =
CLOSER-MOP:STANDARD-GENERIC-FUNCTION)
But before getting sidetracked into CLOSER-MOP, the LW version of =
COMPUTE-APPLICABLE-METHODS returns in one case a direct method with =
specializers (T T) and an :AROUND method for the same specializers. But =
the :AROUND method is listed after the direct method in the result:
(defstruct thing) ;; just to make a unique object type
;; My GF is #=E2=80=99ORD:COMPARE
(compute-applicable-methods #'ord:compare (list (make-thing) =
(make-thing)))
=3D>
(#<STANDARD-METHOD COMPARE NIL (T T) 8280AD7C9B>=20
#<STANDARD-METHOD COMPARE (:AROUND) (T T) 828056D3DB>)
However, at runtime, it becomes clear that my :AROUND method is getting =
called first, as I would have expected. I find this by setting =
breakpoints and then watching the debugger fall through the code.
So next, when I try to call:
(clos:compute-effective-method #'ord:compare=20
clos::*standard-method-combination* ;; =
discovered by probing...
(compute-applicable-methods #'ord:compare =
(list (make-thing) (make-thing))))
=3D>=20
(CALL-METHOD
#<STANDARD-METHOD COMPARE (:AROUND) (T T) 828056D3DB>
((MAKE-METHOD (CALL-METHOD #<STANDARD-METHOD COMPARE NIL (T T) =
8140B0DC03> NIL))))
Whch does indeed show my :AROUND method being called first. But the MOP =
spec says this function should return an effective method and then a =
list of effective method options. And CLOSER-MOP does the same thing as =
the LW version. So both do the =E2=80=9Cwrong=E2=80=9D thing?
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
So, I have long known that LW departs a bit from the extant MOP spec, =
such as it is=E2=80=A6 And I still have no problem with LW way of doing =
things. But it does seem irritating that CLOS:COMPUTE-APPLICABLE-METHODS =
returns results in the=E2=80=9Dincorrect" order...
--Apple-Mail=_5B62876B-8D25-4708-83EF-BDA32453AD96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">Sorry if this opens up a can of worms=E2=80=
=A6 For more than 30 years, I have been a happy Lisper without actually =
ever needing to find the list of applicable methods for a generic =
function being applied to specific arguments. The LW CLOS system just =
performed in the manner I glibly expected.<div><br></div><div>But now, I =
am trying to define a generalized 3-way comparison operation against =
pairs of objects (like a Fortran-IV IF statement). And I have a few =
:AROUND methods, as well as a ton of possibly intersecting direct =
methods against various pairs of argument =
types.</div><div><br></div><div>And so now, looking up how to find which =
methods will be called - CLOS:COMPUTE-APPLICABLE-METHODS. Actually the =
MOP spec states that CLOS:COMPUTE-APPLICABLE-METHODS-USING-CLASSES would =
be called first, and then the former would be called only if the =
-USING-CLASSES returns a false second =
value.</div><div><br></div><div>But LW does not seem to have this =
COMPUTE-APPLICABLE-METHODS-USING-CLASSES. And CLOSER-MOP also claims to =
not have such a method, when I hand it an LW:STANDARD-GENERIC-FUNCTION. =
But it does seem to have it for a CLOSER-MOP:STANDARD-GENERIC-FUNCTION. =
(I guess I should learn how to make a =
CLOSER-MOP:STANDARD-GENERIC-FUNCTION)</div><div><br></div><div>But =
before getting sidetracked into CLOSER-MOP, the LW version of =
COMPUTE-APPLICABLE-METHODS returns in one case a direct method with =
specializers (T T) and an :AROUND method for the same specializers. But =
the :AROUND method is listed after the direct method in the =
result:</div><div><br></div><div><div><font face=3D"Monaco">(defstruct =
thing) ;; just to make a unique object type</font></div><div><font =
face=3D"Monaco"><br></font></div><div><font face=3D"Monaco">;; My GF is =
#=E2=80=99ORD:COMPARE</font></div><div><font =
face=3D"Monaco"><br></font></div><div><div><font =
face=3D"Monaco">(compute-applicable-methods #'ord:compare (list =
(make-thing) (make-thing)))</font></div><div><font =
face=3D"Monaco">=3D></font></div><div><font =
face=3D"Monaco">(#<STANDARD-METHOD COMPARE NIL (T T) =
8280AD7C9B> </font></div><div><font =
face=3D"Monaco">#<STANDARD-METHOD COMPARE (:AROUND) (T T) =
828056D3DB>)</font></div></div></div><div><br></div><div><br></div><div=
>However, at runtime, it becomes clear that my :AROUND method is getting =
called first, as I would have expected. I find this by setting =
breakpoints and then watching the debugger fall through the =
code.</div><div><br></div><div>So next, when I try to =
call:</div><div><br></div><div><div><font =
face=3D"Monaco">(clos:compute-effective-method =
#'ord:compare </font></div><div><font face=3D"Monaco"> =
=
clos::*standard-method-combination* ;; =
discovered by probing...</font></div><div><font face=3D"Monaco"> =
=
(compute-applicable-methods =
#'ord:compare (list (make-thing) =
(make-thing))))</font></div></div><div><font =
face=3D"Monaco"><br></font></div><div><font =
face=3D"Monaco">=3D> </font></div><div><font =
face=3D"Monaco">(CALL-METHOD</font></div><div><font =
face=3D"Monaco"> #<STANDARD-METHOD COMPARE (:AROUND) (T T) =
828056D3DB></font></div><div><font face=3D"Monaco"> ((MAKE-METHOD =
(CALL-METHOD #<STANDARD-METHOD COMPARE NIL (T T) 8140B0DC03> =
NIL))))</font></div><div><br></div><div>Whch does indeed show my :AROUND =
method being called first. But the MOP spec says this function should =
return an effective method and then a list of effective method options. =
And CLOSER-MOP does the same thing as the LW version. So both do the =
=E2=80=9Cwrong=E2=80=9D =
thing?</div><div><br></div><div>=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=
=94=E2=80=94=E2=80=94</div><div><br></div><div>So, I have long known =
that LW departs a bit from the extant MOP spec, such as it is=E2=80=A6 =
And I still have no problem with LW way of doing things. But it does =
seem irritating that CLOS:COMPUTE-APPLICABLE-METHODS returns results in =
the=E2=80=9Dincorrect" =
order...</div><div><br></div><div><br></div><div><br></div></body></html>=
--Apple-Mail=_5B62876B-8D25-4708-83EF-BDA32453AD96--
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html