The CLHS says, in the entry "Local Function CALL-NEXT-METHOD":
[..] The function call-next-method has lexical scope and indefinite
extent and can only be used within the body of a method defined by a
method-defining form.
Whether or not call-next-method is fbound in the global environment
is implementation-dependent; however, the restrictions on
redefinition and shadowing of call-next-method are the same as for
symbols in the COMMON-LISP package which are fbound in the global
environment. The consequences of attempting to use call-next-method
outside of a method-defining form are undefined.
The relationship between extent and "can be used" is not quite clear
to me. Specifically, I'd like to know whether the consequence of the
last form in the following example is well-defined:
(defclass super () ())
(defclass sub (super) ())
(defmethod m ((x super))
'm-on-super)
(defmethod m ((x sub))
#'call-next-method)
(funcall (m (make-instance 'sub)) 'foo)
=> ?
Is this an instance of "attempting to use call-next-method outside of
a method-defining form" or not?
--
Frode Vatvedt Fjeld
* Frode Vatvedt Fjeld
| Is this an instance of "attempting to use call-next-method outside of a
| method-defining form" or not?
No. You have closed over the function.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Tim Bradshaw
Subject: Re: Call-next-method extent and usage
Date:
Message-ID: <ey3elbyq3ku.fsf@cley.com>
* Erik Naggum wrote:
> No. You have closed over the function.
This is right, isn't it. There must be some incredibly cool use for
this...
One think it occurs to me is that it probably makes CLOS
unimplementable in some useless formal sense that ML people will hate.
For instance if I return a closure over CALL-NEXT-METHOD, am I allowed
to change things so that a different method would be invoked before
calling it? (Obviously not).
I have this wonderful vision of strong static typing people lurching
around going `eep, eep' and clutching the transparent covers over
their heads which then explode filling the covers with green goo while
trying to think about this. Actually I often think of strong static
typing people like this anyway (specially the `eep, eep' bit).
--tim (two science fiction movie references in one day, I'm doing well
here)
Tim Bradshaw <···@cley.com> writes:
> > No. You have closed over the function.
>
> This is right, isn't it. There must be some incredibly cool use for
> this...
AFAIR, we actually passed around lexical closures over call-next-method
at my former job :-)
--
(espen)
Tim Bradshaw <···@cley.com> wrote:
+---------------
| I have this wonderful vision of strong static typing people lurching
| around going `eep, eep' and clutching the transparent covers over
| their heads which then explode filling the covers with green goo while
| trying to think about this.
+---------------
"Mars Attacks"? ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <··············@vserver.cs.uit.no>,
Frode Vatvedt Fjeld <······@acm.org> wrote:
>The CLHS says, in the entry "Local Function CALL-NEXT-METHOD":
>
> [..] The function call-next-method has lexical scope and indefinite
> extent and can only be used within the body of a method defined by a
> method-defining form.
>
> Whether or not call-next-method is fbound in the global environment
> is implementation-dependent; however, the restrictions on
> redefinition and shadowing of call-next-method are the same as for
> symbols in the COMMON-LISP package which are fbound in the global
> environment. The consequences of attempting to use call-next-method
> outside of a method-defining form are undefined.
>
>The relationship between extent and "can be used" is not quite clear
>to me. Specifically, I'd like to know whether the consequence of the
>last form in the following example is well-defined:
>
> (defclass super () ())
> (defclass sub (super) ())
> (defmethod m ((x super))
> 'm-on-super)
> (defmethod m ((x sub))
> #'call-next-method)
> (funcall (m (make-instance 'sub)) 'foo)
> => ?
>
>Is this an instance of "attempting to use call-next-method outside of
>a method-defining form" or not?
"Scope" refers to the binding between a name and a value. Since you're not
referring to the name CALL-NEXT-METHOD in the FUNCALL form, nothing in the
second paragraph you quoted is relevant. You're referring to the name
within the body of the method, so you're OK.
"Extent" refers to the usability of the value. Since it has indefinite
extent, you should be able to call the function object at any time.
One way to think of this is that it's as if method-defining forms always
generate the following code for the method body:
(flet ((call-next-method (...) ...))
<original-body>)
Each method body gets its own lexical function binding of CALL-NEXT-METHOD,
and you can pass these around and call them just like any other lexical
function.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> "Extent" refers to the usability of the value. Since it has
> indefinite extent, you should be able to call the function object at
> any time.
It was the words "extent" and "use" that had me confused. I understand
"extent" as you put it above to refer to values' usability, but what
then precisely does the sentence ``The consequences of attempting to
use call-next-method outside of a method-defining form are
undefined.'' refer to? I now assume this refers to implementations
where call-next-method is globally fbound and what would happen with
for example a top-level (call-next-method). Thanks everyone for
putting me straight.
--
Frode Vatvedt Fjeld
In article <··············@vserver.cs.uit.no>,
Frode Vatvedt Fjeld <······@acm.org> wrote:
>Barry Margolin <······@genuity.net> writes:
>
>> "Extent" refers to the usability of the value. Since it has
>> indefinite extent, you should be able to call the function object at
>> any time.
>
>It was the words "extent" and "use" that had me confused. I understand
>"extent" as you put it above to refer to values' usability, but what
>then precisely does the sentence ``The consequences of attempting to
>use call-next-method outside of a method-defining form are
>undefined.'' refer to? I now assume this refers to implementations
>where call-next-method is globally fbound and what would happen with
>for example a top-level (call-next-method). Thanks everyone for
>putting me straight.
You can't read a sentence in a vacuum. When you read that sentence in the
context of the paragraph that contains it, you see that it's talking about
function bindings (the mention of whether it's fbound is the key), so it
must be referring to using the *name* CALL-NEXT-METHOD, not a closure over
the function.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> [..] The function call-next-method has lexical scope and indefinite
> extent ...
> (defmethod m ((x sub))
> #'call-next-method)
> (funcall (m (make-instance 'sub)) 'foo)
> => ?
>
> Is this an instance of "attempting to use call-next-method outside of
> a method-defining form" or not?
The term 'outside' relates to scoping, i.e. to the textual area between
"(defmethod" and ")". Therefore capturing #'call-next-method and calling
it later, as you do here, is valid CL.
However, the argument you pass to it, namely a symbol, leads to an empty
list of applicable methods, whereas with the original argument, there
were two applicable methods. According to CLHS, you will get an error
for this.
Bruno
Bruno Haible <·····@clisp.org> writes:
> However, the argument you pass to it, namely a symbol, leads to an
> empty list of applicable methods, whereas with the original
> argument, there were two applicable methods. According to CLHS, you
> will get an error for this.
Yes, this was actually a typo on my part. What I intended was to call
the call-next-method closure without arguments, so the closed-over
binding of the original argument list would have to be used.
--
Frode Vatvedt Fjeld