Re: Local/temporary methods in CLOS

Liste des GroupesRevenir à cl lisp 
Sujet : Re: Local/temporary methods in CLOS
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.lisp
Date : 12. Mar 2025, 01:08:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250311165922.499@kylheku.com>
References : 1 2 3
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-03-11, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
I need some way to define "local" methods, which can override
temporarily "global" methods and obey some kind of dynamic scoping rule.
>
I feel that your requirements may be somewhere in the locus of
Pastal Costanza's work, like ContextL.
>
https://github.com/pcostanza/contextl
>
Also see Costanza's paper "Dynamically Scoped Functions as the
Essence of AOP" [2003].
>
Thanks!  That's a nice solution, and the underlying implementation
technique makes a lot of sense (it refines the manual solution I've
been playing with).
>
Assuming I'm not the first to feel such a need, what are usual
approaches to try and provide that kind of behavior?
>
Since in Common Lisp we don't have dynamically scoped functions, only
variables, the straightforward thing, without using anyone's framework,
would be to use special variables to hold certain functions of interest,
and funcall them. (That can be wrapped or macroed over.)
>
(defun overridable-fun (&rest args)
  (apply *overridable-fun* args))
>
(let ((*overridable-fun* (lambda (...) ...)))
  (overridable-fun 42))
>
For dynamically-scoped local functions, that's indeed what I typically
use (or alternatively, I simply pass that function explicitly down the
stack), but my question is for the case where I want to do it for
methods, i.e. for "part" of a function (I guess I could simulate it by

OK, so this is something else: dynamically specializing a generic
function with methods which then go away at the end of the scope.

The obvious, but perhaps cumbersome, way which occurs to me for doing
this is to swap the entire generic function for another one
with the mechanisms we have discussed above.

The replacement generic function can have the needed methods.
(But would it still need to? We have all the indirection we need
already.)

I suspect Costanza's ContextL may speaks to these requirements.

You are in some scope in which you would like to modify the behavior
of a generic function, so it has different methods. In "COP"
(context-oriented programming) that behavior would belong to a layer.
You dynamically activate and deactivate the layer (by name, I think).
The layer defines the methods (so physically they are not locally
enclosed in the scope(s) where you are activating the layer). That's a
feature, since you can activate a layer in multiple places.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Date Sujet#  Auteur
11 Mar 25 * Local/temporary methods in CLOS5Stefan Monnier
11 Mar 25 `* Re: Local/temporary methods in CLOS4Kaz Kylheku
11 Mar 25  `* Re: Local/temporary methods in CLOS3Stefan Monnier
12 Mar 25   `* Re: Local/temporary methods in CLOS2Kaz Kylheku
12 Mar 25    `- Re: Local/temporary methods in CLOS1Stefan Monnier

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal