Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Why are methods not functions ?
109 views
Skip to first unread message
Spiros Bousbouras
Dec 24, 2018, 1:03:47 PM12/24/18
to
"7.6.2 Introduction to Methods" says "A method object is not a function and
cannot be invoked as a function." .First I'm not clear if this is a
restriction on implementations i.e. a conforming implementation must not make
a method object FUNCALL-able ; or applications i.e. a portable application
cannot assume that a method object will be FUNCALL-able. Regardless , I would
imagine that every CL implementation implements methods as some kind of
closure so why restrict the possiblity to call them just like functions ?
There may exist occasions where the programmer knows that with some specific
objects a certain method will be called and wants to avoid the overhead
involved in calling the generic function which contains the method and then
the CL system doing dispatch.
--
You think I'm pissed off now ? I'm going to make sure I'm PMSing next week.
Christy Hemme to the "Beautiful people"
http://www.youtube.com/watch?v=cM73g5ILzjM
cannot be invoked as a function." .First I'm not clear if this is a
restriction on implementations i.e. a conforming implementation must not make
a method object FUNCALL-able ; or applications i.e. a portable application
cannot assume that a method object will be FUNCALL-able. Regardless , I would
imagine that every CL implementation implements methods as some kind of
closure so why restrict the possiblity to call them just like functions ?
There may exist occasions where the programmer knows that with some specific
objects a certain method will be called and wants to avoid the overhead
involved in calling the generic function which contains the method and then
the CL system doing dispatch.
--
You think I'm pissed off now ? I'm going to make sure I'm PMSing next week.
Christy Hemme to the "Beautiful people"
http://www.youtube.com/watch?v=cM73g5ILzjM
Jeff Barnett
Dec 24, 2018, 1:29:37 PM12/24/18
to
Spiros Bousbouras wrote on 12/24/2018 11:03 AM:
> "7.6.2 Introduction to Methods" says "A method object is not a function and
> cannot be invoked as a function." .First I'm not clear if this is a
> restriction on implementations i.e. a conforming implementation must not make
> a method object FUNCALL-able ; or applications i.e. a portable application
> cannot assume that a method object will be FUNCALL-able. Regardless , I would
> imagine that every CL implementation implements methods as some kind of
> closure so why restrict the possiblity to call them just like functions ?
> There may exist occasions where the programmer knows that with some specific
> objects a certain method will be called and wants to avoid the overhead
> involved in calling the generic function which contains the method and then
> the CL system doing dispatch.
Methods are combined to make generic functions whose structure is
> "7.6.2 Introduction to Methods" says "A method object is not a function and
> cannot be invoked as a function." .First I'm not clear if this is a
> restriction on implementations i.e. a conforming implementation must not make
> a method object FUNCALL-able ; or applications i.e. a portable application
> cannot assume that a method object will be FUNCALL-able. Regardless , I would
> imagine that every CL implementation implements methods as some kind of
> closure so why restrict the possiblity to call them just like functions ?
> There may exist occasions where the programmer knows that with some specific
> objects a certain method will be called and wants to avoid the overhead
> involved in calling the generic function which contains the method and then
> the CL system doing dispatch.
specialize on the class (type) of the arguments. Generics are
funcall-able but the method pieces are not.
--
Jeff Barnett
Spiros Bousbouras
Dec 24, 2018, 1:34:57 PM12/24/18
to
On Mon, 24 Dec 2018 11:29:35 -0700
Jeff Barnett <j...@notatt.com> wrote:
>
> Methods are combined to make generic functions whose structure is
> specialize on the class (type) of the arguments. Generics are
> funcall-able but the method pieces are not.
Yes , I know that but it doesn't answer my question.
Jeff Barnett <j...@notatt.com> wrote:
>
> Methods are combined to make generic functions whose structure is
> specialize on the class (type) of the arguments. Generics are
> funcall-able but the method pieces are not.
Pascal J. Bourguignon
Dec 24, 2018, 1:40:20 PM12/24/18
to
than funcallable functions.
--
__Pascal J. Bourguignon__
http://www.informatimago.com
Barry Margolin
Dec 24, 2018, 2:38:15 PM12/24/18
to
In article <thXJEjPnzVs14r...@bongo-ra.co>,
implementations. A method could be implemented as a function, but this
allows other implementations as well. It might be an object that
combines a function with data about how it's specialized, and the
function is extracted when creating the combined method for a specific
invocation.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Spiros Bousbouras <spi...@gmail.com> wrote:
> "7.6.2 Introduction to Methods" says "A method object is not a function and
> cannot be invoked as a function." .First I'm not clear if this is a
> restriction on implementations i.e. a conforming implementation must not make
> a method object FUNCALL-able ; or applications i.e. a portable application
> cannot assume that a method object will be FUNCALL-able. Regardless , I would
> imagine that every CL implementation implements methods as some kind of
> closure so why restrict the possiblity to call them just like functions ?
> There may exist occasions where the programmer knows that with some specific
> objects a certain method will be called and wants to avoid the overhead
> involved in calling the generic function which contains the method and then
> the CL system doing dispatch.
I think this is intended as a restriction on applications, not
> "7.6.2 Introduction to Methods" says "A method object is not a function and
> cannot be invoked as a function." .First I'm not clear if this is a
> restriction on implementations i.e. a conforming implementation must not make
> a method object FUNCALL-able ; or applications i.e. a portable application
> cannot assume that a method object will be FUNCALL-able. Regardless , I would
> imagine that every CL implementation implements methods as some kind of
> closure so why restrict the possiblity to call them just like functions ?
> There may exist occasions where the programmer knows that with some specific
> objects a certain method will be called and wants to avoid the overhead
> involved in calling the generic function which contains the method and then
> the CL system doing dispatch.
implementations. A method could be implemented as a function, but this
allows other implementations as well. It might be an object that
combines a function with data about how it's specialized, and the
function is extracted when creating the combined method for a specific
invocation.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
paul wallich
Dec 24, 2018, 10:53:19 PM12/24/18
to
be optimization/safety issues. Because there's a dispatch step, it seems
the code that runs in a method should be able to assume, even at high
safety levels, that it's being called with the thing(s) it's specialized
for. If the method runs as a function, the code can't make that
assumption. Could be dealt with, but not that elegantly.
paul
Kaz Kylheku
Dec 25, 2018, 8:56:00 PM12/25/18
to
On 2018-12-24, Spiros Bousbouras <spi...@gmail.com> wrote:
> "7.6.2 Introduction to Methods" says "A method object is not a function and
> cannot be invoked as a function."
That is defective; such wording should rarely appear in a language
> "7.6.2 Introduction to Methods" says "A method object is not a function and
> cannot be invoked as a function."
standard. It should be "a method object is of a distinct type from
functions, and is not required to be invokable as a function".
That allows implementations to make it so callable if they want.
> First I'm not clear if this is a
> restriction on implementations i.e. a conforming implementation must not make
> a method object FUNCALL-able ; or applications i.e. a portable application
what can be implemented.
> cannot assume that a method object will be FUNCALL-able. Regardless , I would
> imagine that every CL implementation implements methods as some kind of
> closure so why restrict the possiblity to call them just like functions ?
code blob in which they are just branches of code invoked by a case
selection mechanism.
> There may exist occasions where the programmer knows that with some specific
> objects a certain method will be called and wants to avoid the overhead
> involved in calling the generic function which contains the method and then
> the CL system doing dispatch.
a wrapper).
(defmethod foo ((w wiget) (g gadget)))
(foo-widget-gadget w g))
smh
Dec 26, 2018, 8:12:18 AM12/26/18
to
On Tuesday, December 25, 2018 at 5:56:00 PM UTC-8, Kaz Kylheku wrote:
arrays, readtables, hashtables, and streams? There exist Lisp dialect
where some non-function objects are funcallable.
> That allows implementations to make it so callable if they want.
The ANS text you cite is no such prohibition, and is therefore only a
restriction on user programs. To be a prohibition on implementations
some language involving "an error ... signaled" would be necessary.
> > First I'm not clear if this is a
> > restriction on implementations i.e. a conforming implementation must not make
> > a method object FUNCALL-able ; or applications i.e. a portable application
>
> Bingo; it sure looks that way, and so why have such a constraint on
> what can be implemented.
>
> > cannot assume that a method object will be FUNCALL-able. Regardless , I would
> > imagine that every CL implementation implements methods as some kind of
> > closure so why restrict the possiblity to call them just like functions ?
The designers of CLOS realized that in some circumstances superior
performance would require hackery to the ways method functions are called,
or even whether they are called at all (so long as guaranteed semantics are
preserved). For example, real optimizations on real implementations optimize
slot accessor gfs so they operate via permutation tables and don't depend on
method functions working.
Also, method functions do not and cannot perform keyword argument checking
as if they were normal functions -- keyword arg checking can only be
and must be performed by the gf.
> They probably don't, though; methods could well be compiled into one big
> code blob in which they are just branches of code invoked by a case
> selection mechanism.
Reading the ANS as a strict standard, the method-function must exist, but it
has no required semantics if it is called by user code. That why the
arguments and environment in which method code is called is hidden inside
the CALL-METHOD macro [ANS]:
The macro call-method is used in method combination. It hides the
implementation-dependent details of how methods are called.
It's unfortunate that the text you complain about can and has led to
confusion about whether this is a prohibition on the implementation (it
isn't) but remember this ANS is intended only as a standard, not a tutorial,
and (by X3J13 consensus) can only be completely understood by gurus in
consideration of the entire ANS and in consideration with its exceptional
conditions conventions (Error Terminology, Conformance) yada yada yada...
> On 2018-12-24, Spiros Bousbouras wrote:
> > "7.6.2 Introduction to Methods" says "A method object is not a function and
> > cannot be invoked as a function."
>
> That is defective; such wording should rarely appear in a language
> standard. It should be "a method object is of a distinct type from
> functions, and is not required to be invokable as a function".
Disagree. For consistency wouldn't you want similar language regarding
> > "7.6.2 Introduction to Methods" says "A method object is not a function and
> > cannot be invoked as a function."
>
> That is defective; such wording should rarely appear in a language
> standard. It should be "a method object is of a distinct type from
> functions, and is not required to be invokable as a function".
arrays, readtables, hashtables, and streams? There exist Lisp dialect
where some non-function objects are funcallable.
> That allows implementations to make it so callable if they want.
restriction on user programs. To be a prohibition on implementations
some language involving "an error ... signaled" would be necessary.
> > First I'm not clear if this is a
> > restriction on implementations i.e. a conforming implementation must not make
> > a method object FUNCALL-able ; or applications i.e. a portable application
>
> Bingo; it sure looks that way, and so why have such a constraint on
> what can be implemented.
>
> > cannot assume that a method object will be FUNCALL-able. Regardless , I would
> > imagine that every CL implementation implements methods as some kind of
> > closure so why restrict the possiblity to call them just like functions ?
performance would require hackery to the ways method functions are called,
or even whether they are called at all (so long as guaranteed semantics are
preserved). For example, real optimizations on real implementations optimize
slot accessor gfs so they operate via permutation tables and don't depend on
method functions working.
Also, method functions do not and cannot perform keyword argument checking
as if they were normal functions -- keyword arg checking can only be
and must be performed by the gf.
> They probably don't, though; methods could well be compiled into one big
> code blob in which they are just branches of code invoked by a case
> selection mechanism.
has no required semantics if it is called by user code. That why the
arguments and environment in which method code is called is hidden inside
the CALL-METHOD macro [ANS]:
The macro call-method is used in method combination. It hides the
implementation-dependent details of how methods are called.
It's unfortunate that the text you complain about can and has led to
confusion about whether this is a prohibition on the implementation (it
isn't) but remember this ANS is intended only as a standard, not a tutorial,
and (by X3J13 consensus) can only be completely understood by gurus in
consideration of the entire ANS and in consideration with its exceptional
conditions conventions (Error Terminology, Conformance) yada yada yada...
Barry Margolin
Dec 26, 2018, 11:06:40 AM12/26/18
to
In article <pvs9jb$2g7$1...@reader2.panix.com>,
If the spec said that they were functions, I would expect it to state
how they have to be called.
This would be analogous to SETF functions, which expect to be called in
a particular way.
how they have to be called.
This would be analogous to SETF functions, which expect to be called in
a particular way.
Kaz Kylheku
Dec 26, 2018, 12:41:55 PM12/26/18
to
On 2018-12-26, smh <shaf...@gmail.com> wrote:
> On Tuesday, December 25, 2018 at 5:56:00 PM UTC-8, Kaz Kylheku wrote:
>> On 2018-12-24, Spiros Bousbouras wrote:
>> > "7.6.2 Introduction to Methods" says "A method object is not a function and
>> > cannot be invoked as a function."
>>
>> That is defective; such wording should rarely appear in a language
>> standard. It should be "a method object is of a distinct type from
>> functions, and is not required to be invokable as a function".
>
> Disagree. For consistency wouldn't you want similar language regarding
> arrays, readtables, hashtables, and streams?
Yes; I don't think it's productive for the language spec to have wording
> On Tuesday, December 25, 2018 at 5:56:00 PM UTC-8, Kaz Kylheku wrote:
>> On 2018-12-24, Spiros Bousbouras wrote:
>> > "7.6.2 Introduction to Methods" says "A method object is not a function and
>> > cannot be invoked as a function."
>>
>> That is defective; such wording should rarely appear in a language
>> standard. It should be "a method object is of a distinct type from
>> functions, and is not required to be invokable as a function".
>
> Disagree. For consistency wouldn't you want similar language regarding
> arrays, readtables, hashtables, and streams?
which appears to out a funcallable array or hash table.
They should of course have distinct types from functions.
(If there is a type hierarchy where "function" is some abstract type, of
which hashes and arrays are a subtype, that is fine too. Mathematically,
they are functions.)
smh
Dec 28, 2018, 8:41:09 AM12/28/18
to
On Wednesday, December 26, 2018 at 9:41:55 AM UTC-8, Kaz Kylheku wrote:
> > Disagree. For consistency wouldn't you want similar language regarding
> > arrays, readtables, hashtables, and streams?
This is really a meta-comment: Kaz, I know you know the language well and your opinions are well informed, but when writing about a language standard your thoughts would be easier to understand if you used the terminology of that language standard, and used it carefully.
> > Disagree. For consistency wouldn't you want similar language regarding
> > arrays, readtables, hashtables, and streams?
> Yes; I don't think it's productive for the language spec to have wording
> which appears to out a funcallable array or hash table.
sexuality. Did you mean "prohibit"? If so, then we agree.
> They should of course have distinct types from functions.
otherwise when specifically discussing the ANS.
"Distinct" is not the right concept here, since for example the types FUNCTION and GENERIC-FUNCTION are distinct (recognizably different) but
overlapping. A better term in this context might be "disjoint", but I'm not
aware the ANS actually prohibits type overlap between these various object
classes.
> (If there is a type hierarchy where "function" is some abstract type, of
> which hashes and arrays are a subtype, that is fine too. Mathematically,
> they are functions.)
funcallable, and I believe this lack of prohibition was intentional so as not
to preclude extensions. I know of one such example in current, conforming CL
implementations. Allegro allows funcall of a lambda expression (a cons list
beginning with LAMBDA), as if the necessary coerce to a function closure in
the null lexical environment is provided automatically. This was decided
back in the early days of CL since there existed historical pre-lexical-env
Lisp code that depended upon this working, and ease of porting was important.
The extension still exists, and no one complains about it.
Barry Margolin
Dec 28, 2018, 10:50:39 AM12/28/18
to
In article <e955d741-5296-45f6...@googlegroups.com>,
you accessed arrays by calling them as functions. CL doesn't prohibit
implementations providing this compatibility "feature" (does Allegro
have it?).
smh <shaf...@gmail.com> wrote:
> Yes, the ANS does not prohibit an implementation making non-FUNCTIONP objects
> funcallable, and I believe this lack of prohibition was intentional so as not
> to preclude extensions. I know of one such example in current, conforming CL
> implementations. Allegro allows funcall of a lambda expression (a cons list
> beginning with LAMBDA), as if the necessary coerce to a function closure in
> the null lexical environment is provided automatically. This was decided
> back in the early days of CL since there existed historical pre-lexical-env
> Lisp code that depended upon this working, and ease of porting was important.
> The extension still exists, and no one complains about it.
And Steve didn't even mention Maclisp arrays. Maclisp didn't have AREF,
> Yes, the ANS does not prohibit an implementation making non-FUNCTIONP objects
> funcallable, and I believe this lack of prohibition was intentional so as not
> to preclude extensions. I know of one such example in current, conforming CL
> implementations. Allegro allows funcall of a lambda expression (a cons list
> beginning with LAMBDA), as if the necessary coerce to a function closure in
> the null lexical environment is provided automatically. This was decided
> back in the early days of CL since there existed historical pre-lexical-env
> Lisp code that depended upon this working, and ease of porting was important.
> The extension still exists, and no one complains about it.
you accessed arrays by calling them as functions. CL doesn't prohibit
implementations providing this compatibility "feature" (does Allegro
have it?).
smh
Dec 31, 2018, 4:54:44 AM12/31/18
to
On Friday, December 28, 2018 at 7:50:39 AM UTC-8, Barry Margolin wrote:
> And Steve didn't even mention Maclisp arrays. Maclisp didn't have AREF,
> you accessed arrays by calling them as functions. CL doesn't prohibit
> implementations providing this compatibility "feature" (does Allegro
> have it?).
No. It existed only in the ancient Franzlisp dialect, but that was
> And Steve didn't even mention Maclisp arrays. Maclisp didn't have AREF,
> you accessed arrays by calling them as functions. CL doesn't prohibit
> implementations providing this compatibility "feature" (does Allegro
> have it?).
intended as a Maclisp clone for modern machines with a "modern" address space.
Aside from the lambda expression, the only non-functionp objects that are
funcallable are "old Flavors" instances, which are still supported but which receive little use these days.
Stefan Monnier
Feb 14, 2019, 4:21:26 PM2/14/19
to
> "7.6.2 Introduction to Methods" says "A method object is not a function and
> cannot be invoked as a function." .First I'm not clear if this is a
> restriction on implementations i.e. a conforming implementation must not make
> a method object FUNCALL-able ; or applications i.e. a portable application
> cannot assume that a method object will be FUNCALL-able. Regardless , I would
> imagine that every CL implementation implements methods as some kind of
> closure so why restrict the possiblity to call them just like functions ?
I'd be surprised if most CL implementations represent methods as
> cannot be invoked as a function." .First I'm not clear if this is a
> restriction on implementations i.e. a conforming implementation must not make
> a method object FUNCALL-able ; or applications i.e. a portable application
> cannot assume that a method object will be FUNCALL-able. Regardless , I would
> imagine that every CL implementation implements methods as some kind of
> closure so why restrict the possiblity to call them just like functions ?
funcallable objects. They probably could make them funcallable, but
I don't think it comes naturally at all: I expect that method objects
may indeed contain a closure (which may take extra arguments, e.g. for
call-next-method purposes) but even if it does, it also needs to carry
extra information such as its qualifiers and specializers.
Stefan
0 new messages