From attila.lendvai at gmail.com Mon Mar 5 20:28:54 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 5 Mar 2007 21:28:54 +0100 Subject: [closer-devel] the implicit context argument contextl and its implications Message-ID: 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". 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. 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) 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? any toughts? -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) From pc at p-cos.net Thu Mar 8 23:41:26 2007 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 9 Mar 2007 00:41:26 +0100 Subject: [closer-devel] the implicit context argument contextl and its implications In-Reply-To: References: Message-ID: <434DD764-E376-4FDD-B6D6-F1F82C7BF6D0@p-cos.net> 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