[Openmcl-devel] make-method-lambda ?

james anderson james.anderson at setf.de
Wed Sep 10 08:41:20 UTC 2008


On 2008-09-09, at 13:11 , Pascal Costanza wrote:

> You have to keep track of that anyway. The semantics of define-
> manipulated-method is sufficiently different from (standard) defmethod
> that it warrants using different names to make that distinction
> explicit.

my experience has been, that this distinction is academic and can be  
less useful in practice than on paper.
circumstances vary.

> The idea of make-method-lambda is that you can use methods
> defined using defmethod interchangeably with different semantics in
> different contexts/generic functions, but it's actually very unlikely
> that a change of semantics (the fact whether the arguments are
> manipulated or not in your example) will _not_ have an effect on the
> method body.

i am concerned with a case where there is to be no effect. that's the  
point of it.

> So if you have to change the method body because of
> different semantics, you might as well change the defining construct.

moot.

>
> The advantage is that your code is more explicit. I think that makes
> it easier to keep track of things, not harder.

what you suggest is the equivalent of "unrolling" optimization. with  
the attendant benefits and drawbacks. under many circumstances the  
resulting computation is equivalent, but as soon as let-binding and  
re-computation become concerns, the benefits fade.

a thought experiment. method combination objects are in a similar  
"neglected stepchild" position with respect to ensure-generic- 
function as the generic function argument with respect to make-method- 
lambda. it is conceivable to argue, that one could improve the  
situation by implementing compute-effective-method as an inline macro- 
expansion for define-generic-function. that this does not work for  
various reasons, and would be a generally bad idea, suggests the  
drawbacks inherent in inline expansion for make-method-lambda and why  
it runs counter to the mop's paradigm.

>
> We wanted to include such a discussion in the paper, but we haven't
> gotten to a full formulation of the issues involved yet...
>
>
> Pascal
>
> On 9 Sep 2008, at 18:51, james anderson wrote:
>
>> because it's another thing for the developer to keep track of.
>>
>> On 2008-09-09, at 12:26 , Pascal Costanza wrote:
>>
>>> why?
>>>
>>> On 9 Sep 2008, at 16:19, james anderson wrote:
>>>
>>>> i was hoping to avoid define-manipulated-method.
>>>>
>>>> On 2008-09-09, at 09:52 , Pascal Costanza wrote:
>>>>
>>>>>
>>>>> On 9 Sep 2008, at 15:13, james anderson wrote:
>>>>>
>>>>>>> What do you want to achieve? In most cases, there are easier  
>>>>>>> ways
>>>>>>> than make-method-lambda to achieve what you want...
>>>>>>
>>>>>> manipulate the arguments passed to the method.
>>>>>
>>>>>
>>>>> (defmacro define-manipulated-method (name (&rest args) &body body)
>>>>> (let ((unspecialized-args (extract-lambda-list args)))
>>>>>   `(defmethod ,name ,args
>>>>>      (apply (lambda ,unspecialized-args , at body)
>>>>>        (manipulate-args
>>>>>          (list ,@(loop for arg in unspecialized-args
>>>>>                        unless (member arg lambda-list-keywords)
>>>>>                        collect arg)))))))
>>>>>
>>>>> ?!?
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
>>>>> Vrije Universiteit Brussel, Programming Technology Lab
>>>>> Pleinlaan 2, B-1050 Brussel, Belgium
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Openmcl-devel mailing list
>>>> Openmcl-devel at clozure.com
>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>> -- 
>>> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
>>> Vrije Universiteit Brussel, Programming Technology Lab
>>> Pleinlaan 2, B-1050 Brussel, Belgium
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> -- 
> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
> Vrije Universiteit Brussel, Programming Technology Lab
> Pleinlaan 2, B-1050 Brussel, Belgium
>
>
>
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel




More information about the Openmcl-devel mailing list