Sujet : Re: Local/temporary methods in CLOS
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.lispDate : 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/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca