Thanks very much for the explanation. I hadn't given a bit of thought to
how multithreading interacts with type inference. Python does do the
optimizations I expect when the variable is lexically bound. Cool!
From: Christophe Rhodes <csr21@...>
Date: Sat, 31 Jan 2004 09:33:29 +0000
Sender: Christophe Rhodes <csr21@...>
"Robert E. Brown" <bbrown@...> writes:
> The following code:
> (defvar *foo* nil)
> (declaim (type (or null function) *foo*))
> (defun a () (when *foo* (funcall *foo*)))
> (defun b () (if *foo* (funcall *foo*)))
> (defun c () (and *foo* (funcall *foo*)))
> generates 3 compiler messages, one for each of A, B, and C:
> ; note: unable to
> ; optimize away possible call to FDEFINITION at runtime
> ; due to type uncertainty:
> ; The first argument is a (OR NULL FUNCTION), not a FUNCTION.
> In each case, SBCL fails to deduce that *FOO* can only be invoked when it is
> not NIL. I would have guessed that Python's type inferencer could handle
> this sort of thing.
In a threaded sbcl with a shared binding of *foo*, something can
mutate the current binding of *foo* between the test of the
conditional and the execution of the FUNCALL. So the type derivation
would lead to the consequences of an incorrect declaration -- probably
a bus error, in this case, if such a race were to trigger.