[Openmcl-devel] Problems with call-next-method in 1.4-dev-r12912M-trunk (WindowsX8632)
tfb at tfeb.org
Tue Oct 6 10:00:46 UTC 2009
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
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.
More information about the Openmcl-devel