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

[Tim Bradshaw]

On 6 Oct 2009, at 04:24, Matthew D. Swank wrote:

> 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).

In safe code (which is code processed with SAFETY at 3) then "should  
signal an error" means that an error must be signalled, and conforming  
code can rely on that happening (see 1.4.2).  So, if these  
implementations are not signalling an error in that case, they are not  
conforming.

I think it is fairly clear what the purpose of this restriction on  
CALL-NEXT-METHOD is for.  What you want to be able to do is have CALL- 
NEXT-METHOD simply use the set of applicable methods already computed,  
as that may be an expensive computation so you want to have to do it  
no more than once per GF-call.  However, you want to be able to detect  
the case where this will cause something completely mutant to happen  
because you have invoked CALL-NEXT-METHOD with arguments which imply a  
different set of applicable methods.  So, if SAFETY is 3, you can rely  
on the system detecting this (and I think this means it must recompute  
(or retrieve from cache) the set of applicable methods to do this  
check).  If SAFETY is lower, you are allowing it to optimise the call  
by not recomputing the applicable methods.  it's unreasonable to  
assume that an implementation will be able to work out that although  
the applicable methods have changed, all the remaing "next" methods  
(which are not really well-defined if the applicable methods have  
changed) are actually the same.

CCL is clearly conforming here, and it is good that it detects this  
error.  It would be interesting to know if it detects this error when  
safety is lower.

I think the answer, as someone else pointed out, is simple: just punt  
and reinvoke the GF on the new arguments.

--tim

--tim