[Openmcl-devel] Problems with call-next-method in 1.4-dev-r12912M-trunk (WindowsX8632)

Robert Goldman rpgoldman at sift.info
Tue Oct 6 03:34:11 UTC 2009


Matthew D. Swank wrote:
> If that is a correct interpretation, it seems unnecessarily
> restrictive.  Even if previous methods are no longer in the
> compute-applicable-methods list, as long as the identity and ordering of
> subsequent methods don't change, the call to call-next-method with
> the new arguments still follows the same control path.  
> 
> Not that spec interpretation is a democracy, but the reason this came
> up is at least 3 other implementations do not signal an error in this
> case (sbcl clisp abcl).

I believe that RME's interpretation is correct here, and you should
simply do

(foo bar (length baz))

instead of

(call-next-method bar (length baz))

It seems to me that other implementations should not accept this case.
The spec doesn't seem ambiguous here.

best,
R


> 
> Matt
> 
> On Mon, 5 Oct 2009 22:38:14 -0400
> "R. Matthew Emerson" <rme at clozure.com> wrote:
> 
>> Hmm.  The spec says:
>>
>> "When providing arguments to call-next-method, the following rule
>> must be satisfied or an error of type error should be signaled: the
>> ordered set of applicable methods for a changed set of arguments for
>> call-next- method must be the same as the ordered set of applicable
>> methods for the original arguments to the generic function.
>> Optimizations of the error checking are possible, but they must not
>> change the semantics of call-next-method."
>>
>> http://www.lispworks.com/documentation/HyperSpec/Body/f_call_n.htm#call-next-method
>>
>> I understand that to mean that the following has to be true:
>>
>> (equal (compute-applicable-methods #'foo (list 'bar "baz"))
>>         (compute-applicable-methods #'foo (list 'bar 3)))
>>
>> CCL> (compute-applicable-methods #'foo (list 'bar "baz"))
>> (#<STANDARD-METHOD FOO ((EQL BAR) STRING)>
>>   #<STANDARD-METHOD FOO ((EQL BAR) T)>)
>> CCL> (compute-applicable-methods #'foo (list 'bar 3))
>> (#<STANDARD-METHOD FOO ((EQL BAR) T)>)
>> CCL>
>>
>> I wouldn't claim to be a language lawyer, but it does appear to me  
>> that CCL is correct to signal an error in this case.
>>
>>
>> On Oct 5, 2009, at 3:20 PM, Matthew Swank wrote:
>>
>>> This looks like it should work ok:
>>>
>>> CL-USER> (defgeneric foo (bar baz))
>>> #<STANDARD-GENERIC-FUNCTION FOO #xA8F3C1E>
>>>
>>> CL-USER> (defmethod foo ((bar (eql 'bar)) (baz string))
>>> 	   (call-next-method bar (length baz)))
>>> #<STANDARD-METHOD FOO ((EQL BAR) STRING)>
>>>
>>> CL-USER> (defmethod foo ((bar (eql 'bar)) baz)
>>> 	   (cons baz baz))
>>> #<STANDARD-METHOD FOO ((EQL BAR) T)>
>>>
>>> CL-USER> (foo 'bar "baz")
>>>
>>> =>
>>> Applicable-methods changed in call-next-method.
>>> Should be: (#<STANDARD-METHOD FOO ((EQL BAR) STRING)>
>>>            #1=#<STANDARD-METHOD FOO (# T)>)
> 
> 




More information about the Openmcl-devel mailing list