[closer-devel] the implicit context argument contextl and its implications

[Pascal Costanza]

Sorry for the late reply, but I have been quite busy with  
organisational issues for the upcoming International Lisp Conference...

On 5 Mar 2007, at 21:28, Attila Lendvai wrote:

> dear list,
>
> recently i was doing more and more complex stuff with contextl and i
> fooled myself by beliving that the introduced implicit argument is the
> most important in the dispatch.
>
> after quite some time spent on hunting down a behaviour that we didn't
> understand, we finally realiezd that :argument-precedence-order is
> explicitly defined for layered generics and the implicit context
> argument is defined to be the least important in the dispatch.
>
> i think this is not the most useful default value and it should be
> changable when using define-layered-function. i've got some small
> background in subjective dispatch stuff (see the Slate docs and its
> reference at http://slate.tunes.org/doc/progman/ 
> node10.html#SECTION00044700000000000000
> )
> and i had the false assumption that the layer arg is the most
> important, because it's called layer in those docs i've read. these
> docs called the most important "layer" and the least important
> "subject".

OK, this is an issue that I have already thought about a few times,  
and so far I haven't been able to make up my mind about it. I have a  
few (toy) examples in which making the layer argument the least  
significant is useful - this basically allows you to sneak methods in  
between other methods defined on a class hierarchy in the rest of the  
program. If all methods in a layer would be placed in front of all  
other methods, there wouldn't be this possibility available to weave  
methods at such fine grain.

On the other hand, you can easily (at least as I hope) define all  
methods of a layer as :around methods and get the effect of placing  
them all in front of the other layers. It should also be possible to  
define your own method combinations to achieve more "interesting"  
effects.

However, I don't think this is the final word on this issue, and your  
input is definitely interesting. Could you provide more details on  
what the problem is?

(...and for a quick workaround, you probably know how to change the  
macro definition of define-layered-function to get the effect you  
need immediately, right?)

> with the above nomenclature, layers can be used to override big chunks
> of libs/algorithms, while subjects can be used to fine-tune very
> specific parts. contextl, as implemented today, only has subjects.

Yes and no. ContextL also has :around methods, through CLOS.

> this brings up some interesting toughts: layered methods could be
> generalized to contain any number of implicit args (contexts) at any
> position in their dispatch. this may or may not be over-engineering,
> because having both a first and a last implicit argument covers most
> of the cases, but i think i could use for example two implicit first
> args that are two orthogonal contexts. (one would be a layer/context
> representing a gui rendering backend, and the second layer/context
> would represent a gui form that can contain customizations for a
> generic presentation algorith that are specific to that form)

Yes, I think it would be interesting to have an arbitrary number of  
context parameters at hand, not just one. This would be a similar  
generalization as multiple dispatch is to single dispatch. I also  
have an idea for a design and a (hopefully) efficient implementation  
approach, but I am still working on this (and don't hold your breath ;).

> but to get back to something more specific, what do you think about
> moving the context arg to the most important in the dispatch by
> default and/or making it customizable?

See above. What's your response?


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium