From: Wade Humeniuk
Subject: Re: how to call a method returned from find-method
Date:
Message-ID: <Q4rPd.45221$gA4.36885@edtnps89>
·········@yahoo.com wrote:
> I was wondering if it is possible, and if so how, to call a method that
> is returned from find-method. Funcall does not seem to work :(
>
That is probably a really bad idea. Just call the method in the
regular way, the CLOS machinery needs to fully invoked when
calling a method. Just use the generic-function you used in the
find-method and use it in funcall. There is call-method, which
may or not be available, but "Danger Will Robinson!".
Wade
From: Bruno Haible
Subject: Re: how to call a method returned from find-method
Date:
Message-ID: <culorm$kul$1@laposte.ilog.fr>
> I was wondering if it is possible, and if so how, to call a method that
> is returned from find-method. Funcall does not seem to work :(
On platforms supporting the MOP, yes, it is possible in a portable way.
(CLOS:METHOD-FUNCTION method) returns the actual function code contained
in the method. The parameters that it expects are: 1. The list of arguments,
2. the list of "next methods".
Example:
(defgeneric foo (x)
(:method ((x integer)) (isqrt x))
(:method ((x real)) (sqrt (float x))))
(setq my-method (find-method #'foo nil (list (find-class 'real))))
(setq my-arglist (list 43))
(funcall (clos:method-function my-method) my-arglist '())
=> 6.5574384
Bruno
Bruno Haible <·····@clisp.org> wrote:
+---------------
| > I was wondering if it is possible, and if so how, to call a method that
| > is returned from find-method. Funcall does not seem to work :(
|
| On platforms supporting the MOP, yes, it is possible in a portable way.
| (CLOS:METHOD-FUNCTION method) returns the actual function code contained
| in the method.
+---------------
Note that in CMUCL that needs to be PCL:METHOD-FUNCTION,
but other than that Bruno's example works as shown there, too.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Bruno Haible <·····@clisp.org> wrote:
[...]
> | On platforms supporting the MOP, yes, it is possible in a portable way.
> | (CLOS:METHOD-FUNCTION method) returns the actual function code contained
> | in the method.
> +---------------
>
> Note that in CMUCL that needs to be PCL:METHOD-FUNCTION,
> but other than that Bruno's example works as shown there, too.
Looking forward to Pascal Costanza's Closer :)
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Rob Warnock wrote:
>| (CLOS:METHOD-FUNCTION method)
>
> Note that in CMUCL that needs to be PCL:METHOD-FUNCTION,
Yes, and it's annoying that the implementations don't provide a unique
package name for their MOP implementation.
Allegro: "CLOS"
GNU clisp: "CLOS"
LispWorks: "CLOS"
GNU gcl: "PCL"
CMUCL: "PCL"
SBCL: "SB-PCL"
OpenMCL: "OPENMCL-MOP"
It's time for all implementations to support the name "CLOS" as a nickname,
at least. Otherwise portable code needs to carry around stuff like this
eternally:
#-(or CLISP ALLEGRO LISPWORKS)
(let ((packname
#+SBCL "SB-PCL" ; or "SB-MOP"?
#+CMU "PCL" ; or "MOP"?
#+OpenMCL "OPENMCL-MOP" ; or "CCL" ?
))
#+SBCL (unlock-package packname)
(rename-package packname packname
(cons "CLOS" (package-nicknames packname))))
Bruno
Bruno Haible <·····@clisp.org> writes:
> Rob Warnock wrote:
> >| (CLOS:METHOD-FUNCTION method)
> >
> > Note that in CMUCL that needs to be PCL:METHOD-FUNCTION,
>
> Yes, and it's annoying that the implementations don't provide a unique
> package name for their MOP implementation.
>
> Allegro: "CLOS"
Note first that the implementation of the MOP is actually internally
implemented in Allegro's EXCL package, because it is just part of
CLOS and is integrated with the rest of the lisp in our general
implementation package. The package which _exports_ the MOP
interface has CLOS as a nicknme, but its actual name is ACLMOP,
to keep from confiscating any generic names (if done carefully,
users can use rename-package to grab nicknames they want to use
for other purposes). The nicknames for the ACLMOP package are
MOP, CLOS (of course), and ACL-MOP (for back-compatibility; some
don't like hyphens in package names for esthetic reasons).
> GNU clisp: "CLOS"
> LispWorks: "CLOS"
I have no problem with CLOS as a name for MOP functions, and we use
it in Allegro CL for backward compatibility for traditional usages
of MOP functions. However, it is ironic that those CLOS names which
are explicitly specified by ANS cannot be homed in a separate CLOS
package, since they are in the Common Lisp package. In our own
source code, we tend to use MOP as the package identifier, as in
(mop:generic-function-methods #'print-object)
> GNU gcl: "PCL"
> CMUCL: "PCL"
> SBCL: "SB-PCL"
PCL is not CLOS, and that is why through the years we took references
to PCL out of our code, as we tried to work toward more CLOS conformance
and MOP agreement.
> OpenMCL: "OPENMCL-MOP"
This would seem like a good package name if CLOS were added as a
nickname.
> It's time for all implementations to support the name "CLOS" as a nickname,
> at least. Otherwise portable code needs to carry around stuff like this
> eternally:
>
> #-(or CLISP ALLEGRO LISPWORKS)
> (let ((packname
> #+SBCL "SB-PCL" ; or "SB-MOP"?
> #+CMU "PCL" ; or "MOP"?
> #+OpenMCL "OPENMCL-MOP" ; or "CCL" ?
> ))
> #+SBCL (unlock-package packname)
> (rename-package packname packname
> (cons "CLOS" (package-nicknames packname))))
I agree. But why CLOS, and not MOP? CLOS (the system) is already
standardized, and is part of Common Lisp, and the interface functions
mentioned in the standard are mandated to be in the Common Lisp package.
The name MOP more closely reflects the intention of those functions
which are not part of Common Lisp but which align themselves to the
MOP.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> The nicknames for the ACLMOP package are MOP, CLOS (of course), and ACL-MOP
Yes. You say "of course", but some implementors are only starting to
understand that this nickname would be valuable.
> However, it is ironic that those CLOS names which
> are explicitly specified by ANS cannot be homed in a separate CLOS
> package, since they are in the Common Lisp package.
Huh? The home package of these symbols are not fixed by ANSI CL, only
the fact that they are exported from the COMMON-LISP package is:
(find-symbol "DEFCLASS" "COMMON-LISP") => DEFCLASS; :EXTERNAL
(symbol-package 'defclass) => unspecified
An implementation can therefore define DEFCLASS as CLOS:DEFCLASS and
re-export it from the COMMON-LISP package.
> why CLOS, and not MOP?
1) Half of the implementations already support the nickname "CLOS",
but less implementations call it "MOP".
2) Some of the implementations' MOP support is so incomplete and buggy
that it would be arrogant if they would use "MOP" as a package name.
Bruno
Bruno Haible <·····@clisp.org> writes:
> Duane Rettig wrote:
>
> > The nicknames for the ACLMOP package are MOP, CLOS (of course), and ACL-MOP
>
> Yes. You say "of course", but some implementors are only starting to
> understand that this nickname would be valuable.
Perhaps, but I still feel that MOP is more descriptive than
CLOS.
> > However, it is ironic that those CLOS names which
> > are explicitly specified by ANS cannot be homed in a separate CLOS
> > package, since they are in the Common Lisp package.
>
> Huh? The home package of these symbols are not fixed by ANSI CL, only
> the fact that they are exported from the COMMON-LISP package is:
>
> (find-symbol "DEFCLASS" "COMMON-LISP") => DEFCLASS; :EXTERNAL
> (symbol-package 'defclass) => unspecified
>
> An implementation can therefore define DEFCLASS as CLOS:DEFCLASS and
> re-export it from the COMMON-LISP package.
Yes, I was being loose with my terminology, as I was considering all of
the explicit restrictons there are on symbols _contained_ in the Common
Lisp package (see 11.1.2.1) and so I suppose I should have used
the word _contained_. I suppose that my own logic got the better of
me, because if any enforcement of the 11.1.2.1.2 restrictions are to
be done efficiently (perhaps on a per-package basis) then if any such
symbols have their home in a package other than Common Lisp, then that
package must also obey the same rules, and might be a candidate for the
same checks that are given to symbols actually homed in Common Lisp.
It is, in other words, _as_ _if_ the symbols had been homed there.
> > why CLOS, and not MOP?
>
> 1) Half of the implementations already support the nickname "CLOS",
> but less implementations call it "MOP".
Well, it is trivial to add nicknames of either flavor.
> 2) Some of the implementations' MOP support is so incomplete and buggy
> that it would be arrogant if they would use "MOP" as a package name.
Then nobody could really name a package MOP. I think the lessons
Paul Dietz taught us with his test suite, and Kent Pitman's foresight
in coining his phrase "purports to conform" makes me believe we might
use similar concepts for "conformance" to the MOP as well. But since
the MOP isn't even a formal standard, it is not always even clear what
"inomplete and buggy" really mean.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
> > > why CLOS, and not MOP?
> >
> > 1) Half of the implementations already support the nickname "CLOS",
> > but less implementations call it "MOP".
>
> Well, it is trivial to add nicknames of either flavor.
True. Just done this in CLISP. So from the perspective of the package
name "MOP", the picture is now this:
Allegro: "MOP"
GNU clisp: "MOP"
CMUCL: "MOP"
SBCL: "SB-MOP"
OpenMCL: "OPENMCL-MOP"
LispWorks: "CLOS"
GNU gcl: "PCL"
Still waiting for SBCL, OpenMCL and the others...
Bruno
Duane Rettig wrote:
>
> I agree. But why CLOS, and not MOP?
Because "MOP" is already a name or a nickname in some implementations.
Hence it'd be better to have "CLOS-MOP" or "CLOS.MOP" (which, AFAIK, are
unused) with the understanding that the symbols exported have "more
compatibility" than the current situation.
CLOS (the system) is already
> standardized, and is part of Common Lisp, and the interface functions
> mentioned in the standard are mandated to be in the Common Lisp package.
> The name MOP more closely reflects the intention of those functions
> which are not part of Common Lisp but which align themselves to the
> MOP.
>
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Duane Rettig wrote:
> > I agree. But why CLOS, and not MOP?
>
>
> Because "MOP" is already a name or a nickname in some
> implementations. Hence it'd be better to have "CLOS-MOP" or "CLOS.MOP"
> (which, AFAIK, are unused) with the understanding that the symbols
> exported have "more compatibility" than the current situation.
I can agree with this (and it is easy enough, as I've said elsewhere,
to add package nicknames), but out of curiosity, why the big deal
against MOP (and not against CLOS)? I.e., are there any
implementations that have MOP as a package name or nickname for which
that name does _not_ already mean the MOP for CLOS?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Duane Rettig wrote:
>>
>>>I agree. But why CLOS, and not MOP?
>>
>>
>>Because "MOP" is already a name or a nickname in some
>>implementations. Hence it'd be better to have "CLOS-MOP" or "CLOS.MOP"
>>(which, AFAIK, are unused) with the understanding that the symbols
>>exported have "more compatibility" than the current situation.
>
>
> I can agree with this (and it is easy enough, as I've said elsewhere,
> to add package nicknames), but out of curiosity, why the big deal
> against MOP (and not against CLOS)? I.e., are there any
> implementations that have MOP as a package name or nickname for which
> that name does _not_ already mean the MOP for CLOS?
>
In principle there is nothing wrong in choosing MOP. But I like the
idea of putting all the implementations on the same level with a fresh
start, and to have a way to distinguish between the implemetation of the
MOP per se and "compatibility" with the AMOP.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Duane Rettig wrote:
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
>
> >>Duane Rettig wrote:
> >>
> >>>I agree. But why CLOS, and not MOP?
> >>
> >>
> >>Because "MOP" is already a name or a nickname in some
> >>implementations. Hence it'd be better to have "CLOS-MOP" or "CLOS.MOP"
> >>(which, AFAIK, are unused) with the understanding that the symbols
> >>exported have "more compatibility" than the current situation.
> > I can agree with this (and it is easy enough, as I've said elsewhere,
>
> > to add package nicknames), but out of curiosity, why the big deal
> > against MOP (and not against CLOS)? I.e., are there any
> > implementations that have MOP as a package name or nickname for which
> > that name does _not_ already mean the MOP for CLOS?
> >
>
>
> In principle there is nothing wrong in choosing MOP. But I like the
> idea of putting all the implementations on the same level with a fresh
> start, and to have a way to distinguish between the implemetation of
> the MOP per se and "compatibility" with the AMOP.
The only way to distinguish a level of compatibility with AMOP is
via a test suite. Paul Dietz is certainly not doing that; AMOP falls
outside of his test suite's domain, since it is not a standard. Do
you have or know of such an AMOP compatibility test suite in the works?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Duane Rettig wrote:
>>
>>>Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>
>>
>>>>Duane Rettig wrote:
>>>>
>>>>
>>>>>I agree. But why CLOS, and not MOP?
>>>>
>>>>
>>>>Because "MOP" is already a name or a nickname in some
>>>>implementations. Hence it'd be better to have "CLOS-MOP" or "CLOS.MOP"
>>>>(which, AFAIK, are unused) with the understanding that the symbols
>>>>exported have "more compatibility" than the current situation.
>>>
>>>I can agree with this (and it is easy enough, as I've said elsewhere,
>>
>>>to add package nicknames), but out of curiosity, why the big deal
>>>against MOP (and not against CLOS)? I.e., are there any
>>>implementations that have MOP as a package name or nickname for which
>>>that name does _not_ already mean the MOP for CLOS?
>>>
>>
>>
>>In principle there is nothing wrong in choosing MOP. But I like the
>>idea of putting all the implementations on the same level with a fresh
>>start, and to have a way to distinguish between the implemetation of
>>the MOP per se and "compatibility" with the AMOP.
>
>
> The only way to distinguish a level of compatibility with AMOP is
> via a test suite. Paul Dietz is certainly not doing that; AMOP falls
> outside of his test suite's domain, since it is not a standard. Do
> you have or know of such an AMOP compatibility test suite in the works?
>
Looks like Pascal Costanza is working on this. Check out the CLOSER
project on common-lisp.net.
Cheers
--
Marco
Duane Rettig wrote:
>> The only way to distinguish a level of compatibility with AMOP is
>> via a test suite. Paul Dietz is certainly not doing that; AMOP falls
>> outside of his test suite's domain, since it is not a standard. Do
>> you have or know of such an AMOP compatibility test suite in the works?
GNU clisp contains a testsuite that covers all important features of MOP
(except MAKE-METHOD-LAMBDA). So far, this testsuite has found bugs in
all of Allegro, LispWorks, CMUCL, SBCL, OpenMCL, GCL. It also manages
to crash SBCL, OpenMCL and LispWorks.
Here is how to use it:
- Check out the clisp CVS, subdirectory clisp/tests.
$ cd clisp/tests
$ lisp
> (load "tests.lisp")
> (run-test "clos")
> (run-test "mop")
Bruno
Duane Rettig <·····@franz.com> writes:
> The only way to distinguish a level of compatibility with AMOP is
> via a test suite. Paul Dietz is certainly not doing that; AMOP falls
> outside of his test suite's domain, since it is not a standard. Do
> you have or know of such an AMOP compatibility test suite in the works?
pascal costanza has started one:
http://common-lisp.net/project/closer/
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
·······················@typhoon.nyu.edu...
>
>
> Duane Rettig wrote:
> >
> > I agree. But why CLOS, and not MOP?
>
> Because "MOP" is already a name or a nickname in some implementations.
> Hence it'd be better to have "CLOS-MOP" or "CLOS.MOP" (which, AFAIK, are
> unused) with the understanding that the symbols exported have "more
> compatibility" than the current situation.
I don't think (clos.mop:foo x y) will do what you expect.
Gorbag wrote:
> "Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
> ·······················@typhoon.nyu.edu...
>
>>
>>Duane Rettig wrote:
>>
>>>I agree. But why CLOS, and not MOP?
>>
>>Because "MOP" is already a name or a nickname in some implementations.
>>Hence it'd be better to have "CLOS-MOP" or "CLOS.MOP" (which, AFAIK, are
>>unused) with the understanding that the symbols exported have "more
>>compatibility" than the current situation.
>
>
> I don't think (clos.mop:foo x y) will do what you expect.
>
That depends on what I am expecting. I do not understand your comment.
Cheers
--
marco
Hi all.
Duane Rettig wrote:
>> GNU gcl: "PCL"
>> CMUCL: "PCL"
>> SBCL: "SB-PCL"
>
> PCL is not CLOS, and that is why through the years we took references
> to PCL out of our code, as we tried to work toward more CLOS conformance
> and MOP agreement.
I had previously thought that PCL was just an implementation of CLOS, so for
interests sake, could I please ask someone to briefly (probably not the best
word, but anyway...) outline the history of CLOS in the major Common Lisp
implementations in terms of original source derivation?
Particularly, I'm aware of the existence of PCL and Closette and I am
curious about their origins, historical influence and their relationship to
CLOS per se, including advantages/disadvantages.
Cheers
Mike Thomas.
Bruno Haible <·····@clisp.org> writes:
> GNU gcl: "PCL"
> CMUCL: "PCL"
> SBCL: "SB-PCL"
Don't know, no, and no. For CMUCL and SBCL, these are the packages
that *implement* the MOP functions. MOP and SB-MOP are the interface.
Bruno Haible wrote:
> Rob Warnock wrote:
>
>>| (CLOS:METHOD-FUNCTION method)
>>
>>Note that in CMUCL that needs to be PCL:METHOD-FUNCTION,
>
>
> Yes, and it's annoying that the implementations don't provide a unique
> package name for their MOP implementation.
>
> Allegro: "CLOS"
> GNU clisp: "CLOS"
> LispWorks: "CLOS"
> GNU gcl: "PCL"
> CMUCL: "PCL"
> SBCL: "SB-PCL"
> OpenMCL: "OPENMCL-MOP"
>
> It's time for all implementations to support the name "CLOS" as a nickname,
> at least.
I second that. I'd choose the nickname "CLOS-MOP" or "CLOS.MOP"
though. CLOS is already part of CL after all. It is the MOP that it is
not. Would you have clos:defgeneric in your setup?
Moreover, you also need to ensure a minimum of functionality shared
among implementations. AFAIU, this is what Pascal's CLOSER strives for.
Cheers
Marco
Otherwise portable code needs to carry around stuff like this
> eternally:
>
> #-(or CLISP ALLEGRO LISPWORKS)
> (let ((packname
> #+SBCL "SB-PCL" ; or "SB-MOP"?
> #+CMU "PCL" ; or "MOP"?
> #+OpenMCL "OPENMCL-MOP" ; or "CCL" ?
> ))
> #+SBCL (unlock-package packname)
> (rename-package packname packname
> (cons "CLOS" (package-nicknames packname))))
>
> Bruno
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Bruno Haible wrote:
> > Rob Warnock wrote:
> >
> >>| (CLOS:METHOD-FUNCTION method)
> >>
> >>Note that in CMUCL that needs to be PCL:METHOD-FUNCTION,
> > Yes, and it's annoying that the implementations don't provide a
> > unique
> > package name for their MOP implementation.
> > Allegro: "CLOS"
> > GNU clisp: "CLOS"
> > LispWorks: "CLOS"
> > GNU gcl: "PCL"
> > CMUCL: "PCL"
> > SBCL: "SB-PCL"
> > OpenMCL: "OPENMCL-MOP"
> > It's time for all implementations to support the name "CLOS" as a
> > nickname,
> > at least.
>
>
> I second that. I'd choose the nickname "CLOS-MOP" or "CLOS.MOP"
I make my package names like in Java: "COM.DTPQ.FOO".
I know some other people do this, but I'm not sure how popular that is.
Is there some need to distinguish the toplevel MOP from some
other toplevel MOP that is not part of CLOS?
······@news.dtpq.com (Christopher C. Stacy) writes:
> Is there some need to distinguish the toplevel MOP from some
> other toplevel MOP that is not part of CLOS?
Given the implementation standard (and the 'specification' standard,
for that matter) of the MOP-as-described-in-AMOP, it could well be
perfectly reasonable to want to distinguish the
MOP-as-described-in-AMOP from the MOP which is actually implemented,
from any given vendor.
Christophe
Christophe Rhodes wrote:
>
> Given the implementation standard (and the 'specification' standard,
> for that matter) of the MOP-as-described-in-AMOP, it could well be
> perfectly reasonable to want to distinguish the
> MOP-as-described-in-AMOP from the MOP which is actually implemented,
> from any given vendor.
Sure. There is no objection against vendor specific package names like
"SB-MOP", "OPENMCL-MOP", "ACL-MOP", "CLISP-MOP", etc., as long as a
standardized name - say, "MOP", as proposed by Duane Rettig - always
refers to the MOP-as-described-in-AMOP.
Bruno
Christopher C. Stacy wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>>
>>
>>I second that. I'd choose the nickname "CLOS-MOP" or "CLOS.MOP"
>
>
> I make my package names like in Java: "COM.DTPQ.FOO".
> I know some other people do this, but I'm not sure how popular that is.
I do. I find it quite useful. The Java naming scheme is a good idea
and it serves the purpose of clarifying - at a minimum - hierarchical
relationships among packages. (Cfr. my CL-UNIFICATION package in
common-lisp.net)
On top of that, ACL and CMUCL can grok the dot notation in interesting ways.
>
> Is there some need to distinguish the toplevel MOP from some
> other toplevel MOP that is not part of CLOS?
>
I think the main issue is actual compliance with the AMOP vs the
specific MOP implemented in a given implementation. Using a "new"
package name will clarify that the symbols exported strives for
compatibility with the AMOP. Of course, this sweeps under the carpet
the issues with the AMOP itself, but Pascal Costanza is workign on it :)
Cheers
--
Marco
Bruno Haible <·····@clisp.org> writes:
> Yes, and it's annoying that the implementations don't provide a unique
> package name for their MOP implementation.
>
> SBCL: "SB-PCL"
No.
Christophe
Bruno Haible wrote:
> On platforms supporting the MOP, yes, it is possible in a portable way.
> (CLOS:METHOD-FUNCTION method) returns the actual function code contained
> in the method. The parameters that it expects are: 1. The list of arguments,
> 2. the list of "next methods".
I'm not sure this is true, portably. See make-method and call-method in the
ANS. These conspire to hide the implementation-dependent way that a
method-function is actually called.
> (defgeneric foo (x)
> (:method ((x integer)) (isqrt x))
> (:method ((x real)) (sqrt (float x))))
> (setq my-method (find-method #'foo nil (list (find-class 'real))))
> (setq my-arglist (list 43))
> (funcall (clos:method-function my-method) my-arglist '())
I'm pretty sure in ACL that if a method does not call call-next-method
of next-method-p, the list of next methods is not passed to it (and is
not even computed if nobody else needs it). This is an important
efficiency optimization, and I am not aware that it violates either
the ANS or the MOP.
From: Bruno Haible
Subject: Re: how to call a method returned from find-method
Date:
Message-ID: <cvctou$3nt$1@laposte.ilog.fr>
Steven M. Haflich wrote:
>> On platforms supporting the MOP, yes, it is possible in a portable way.
>> (CLOS:METHOD-FUNCTION method) returns the actual function code contained
>> in the method. The parameters that it expects are: 1. The list of arguments,
>> 2. the list of "next methods".
>
> I'm not sure this is true, portably. See make-method and call-method in the
> ANS. These conspire to hide the implementation-dependent way that a
> method-function is actually called.
In ANSI CL, the details of method calls are hidden, indeed.
The MOP, however, specifies it quite explicitly. See
http://www.lisp.org/mop/dictionary.html, section MAKE-METHOD-LAMBDA:
"When a method is actually called by an effective method, its first
argument will be a list of the arguments to the generic function.
Its remaining arguments will be all but the first argument passed
to call-method. By default, all method functions must accept two
arguments: the list of arguments to the generic function and the
list of next methods."
>> (defgeneric foo (x)
>> (:method ((x integer)) (isqrt x))
>> (:method ((x real)) (sqrt (float x))))
>> (setq my-method (find-method #'foo nil (list (find-class 'real))))
>> (setq my-arglist (list 43))
>> (funcall (clos:method-function my-method) my-arglist '())
>
> I'm pretty sure in ACL that if a method does not call call-next-method
> of next-method-p, the list of next methods is not passed to it (and is
> not even computed if nobody else needs it). This is an important
> efficiency optimization, and I am not aware that it violates either
> the ANS or the MOP.
This is of course an important optimization. CLISP and the PCL based
CLOS implementations do this optimization in a way that is invisible
to the MOP user. In other words, the above example works fine in CLISP
and implementations with PCL, but it fails in ACL 6.2. Conclusion: ACL 6.2
does not implement the MOP protocol for effective method calls.
Bruno