Hi! Does anyone know why the non-standard built-in method combinations do not support before and after methods? Thanks. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
* Didier Verna <qvqvre@yeqr.rcvgn.se> [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://ffii.org http://camera.org http://think-israel.org http://no2bds.org Do not worry about which side your bread is buttered on: you eat BOTH sides.
Ah, but the OP specified "built-in" along with "non-standard". hth -hk On Wed, May 17, 2017 at 3:24 PM, Sam Steingold <sds@gnu.org> wrote:
* Didier Verna <qvqvre@yeqr.rcvgn.se> [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
-- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://ffii.org http://camera.org http://think-israel.org http://no2bds.org Do not worry about which side your bread is buttered on: you eat BOTH sides.
-- *Ken **Tilton *|Software Engineer *w:* (555) 555-5555 *e:* ken.tilton@weather.com <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps>
You're apparently confusing two different meaning of "standard". It's not the meaning that something is defined in the ANS and therefore built into the standard ANSI CL language. Rather, it is a standard method-combination that is not the one known as STANDARD-METHOD-COMBINATION. On Wed, May 17, 2017 at 1:50 PM, Ken Tilton <ken.tilton@weather.com> wrote:
Ah, but the OP specified "built-in" along with "non-standard".
hth
-hk
On Wed, May 17, 2017 at 3:24 PM, Sam Steingold <sds@gnu.org> wrote:
* Didier Verna <qvqvre@yeqr.rcvgn.se> [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
-- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://ffii.org http://camera.org http://think-israel.org http://no2bds.org Do not worry about which side your bread is buttered on: you eat BOTH sides.
-- *Ken **Tilton *|Software Engineer *w:* (555) 555-5555 *e:* ken.tilton@weather.com <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps>
As for the original question, I don't see any reason the various built-in method combination could not have been defined to support :before and :after methods. But the way they are defined is consonant with the short form of define-method-combination, which implies that the several built-in method combinations would typically be implemented using short form d-m-c. So the scope of the original question probably should be expanded to include short form d-m-c. On Fri, May 19, 2017 at 6:20 PM, Steve Haflich <shaflich@gmail.com> wrote:
You're apparently confusing two different meaning of "standard". It's not the meaning that something is defined in the ANS and therefore built into the standard ANSI CL language. Rather, it is a standard method-combination that is not the one known as STANDARD-METHOD-COMBINATION.
On Wed, May 17, 2017 at 1:50 PM, Ken Tilton <ken.tilton@weather.com> wrote:
Ah, but the OP specified "built-in" along with "non-standard".
hth
-hk
On Wed, May 17, 2017 at 3:24 PM, Sam Steingold <sds@gnu.org> wrote:
* Didier Verna <qvqvre@yeqr.rcvgn.se> [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
-- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://ffii.org http://camera.org http://think-israel.org http://no2bds.org Do not worry about which side your bread is buttered on: you eat BOTH sides.
-- *Ken **Tilton *|Software Engineer *w:* (555) 555-5555 *e:* ken.tilton@weather.com <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps> <http://weather.com/apps>
Steve Haflich <shaflich@gmail.com> wrote:
As for the original question, I don't see any reason the various built-in method combination could not have been defined to support :before and :after methods. But the way they are defined is consonant with the short form of define-method-combination, which implies that the several built-in method combinations would typically be implemented using short form d-m-c. So the scope of the original question probably should be expanded to include short form d-m-c.
Good point. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
Dnia 2017-05-17, śro o godzinie 15:24 -0400, Sam Steingold pisze:
* Didier Verna <qvqvre@yeqr.rcvgn.se> [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
But Didier is asking about BUILT-IN method combinations. Possibly it was hard to define reasonable agreed semantics for before an after methods in the case of something like AND or APPEND (technical troubles aside). Regards ZJ
zbyszek <zbyszek@mimuw.edu.pl> wrote:
Dnia 2017-05-17, śro o godzinie 15:24 -0400, Sam Steingold pisze:
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
But Didier is asking about BUILT-IN method combinations. Possibly it was hard to define reasonable agreed semantics for before an after methods in the case of something like AND or APPEND (technical troubles aside).
Right. I was merely curious. It's pretty obvious to me why you wouldn't allow CALL-NEXT-METHOD in non-standard built-in combinations, but I can't figure out why or how before and after methods could be problematic, so I was wondering... -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
On 18 May 2017, at 10:42, Didier Verna <didier@lrde.epita.fr> wrote:
zbyszek <zbyszek@mimuw.edu.pl> wrote:
Dnia 2017-05-17, śro o godzinie 15:24 -0400, Sam Steingold pisze:
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
But Didier is asking about BUILT-IN method combinations. Possibly it was hard to define reasonable agreed semantics for before an after methods in the case of something like AND or APPEND (technical troubles aside).
Right. I was merely curious. It's pretty obvious to me why you wouldn't allow CALL-NEXT-METHOD in non-standard built-in combinations, but I can't figure out why or how before and after methods could be problematic, so I was wondering...
I’m just guessing, but one reason I can think of is that almost all of the built-in method combinations (except for standard and progn) are applicative. before/after methods don’t have a direct impact on the return value of a generic function call, so their primary purpose is to allow for specifying side effects, which presumably doesn’t make a lot of sense for applicative combinators. Does that make any sense? Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Pascal Costanza wrote:
I’m just guessing, but one reason I can think of is that almost all of the built-in method combinations (except for standard and progn) are applicative. before/after methods don’t have a direct impact on the return value of a generic function call, so their primary purpose is to allow for specifying side effects, which presumably doesn’t make a lot of sense for applicative combinators.
Does that make any sense?
Hmmm. Nope :-) Not much to me at least. I have several cases where I would have liked to be able to perform some kinds of sanity checks before executing a combination such as AND OR etc. I can still manage to do it in an around method, but it feels wrong. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info
On 18 May 2017, at 11:05, Didier Verna <didier@lrde.epita.fr> wrote:
Pascal Costanza wrote:
I’m just guessing, but one reason I can think of is that almost all of the built-in method combinations (except for standard and progn) are applicative. before/after methods don’t have a direct impact on the return value of a generic function call, so their primary purpose is to allow for specifying side effects, which presumably doesn’t make a lot of sense for applicative combinators.
Does that make any sense?
Hmmm. Nope :-)
Darn. :-) -- Pascal Costanza
participants (6)
-
Didier Verna -
Ken Tilton -
Pascal Costanza -
Sam Steingold -
Steve Haflich -
zbyszek