[slime-devel] Re: function/symbol-function and thread binding bug?

[Rudi Schlatte]

"Tobias C. Rittweiler" <tcr at freebits.de> writes:

> szergling <senatorzergling at gmail.com> writes:
>
>> Hi folks,
>>
>> Perhaps I've confused myself a bit here, but there seem to be
>> something wrong with either Slime (most likely), SBCL threads, or my
>> understanding of the difference between (funcall 'print-something) and
>> (funcall #'print-something).
>>
>> Could someone confirm the following behaviour? 
>
> This is not a Slime issue; the analysis seems correct, though. You
> shouldn't rely on this behaviour programmatically. HTH.
>

I say it's a misunderstanding of the difference between the two
funcall examples.  You can rely on

(let ((that-which-i-want-to-call 'print-something))
  (funcall that-which-i-want-to-call))

and

(let ((that-which-i-want-to-call #'print-something))
  (funcall that-which-i-want-to-call))

to have different semantics.  This is not a bug.

funcall takes a function designator, which can be a symbol or a
function.  If funcall is called with 'print-something, it picks up the
function that that is currently residing in print-something's function
cell.  But a redefinition of print-something (which is just storing a
new value in that symbol's function cell) doesn't magically hunt down
and overwrite every function object (now not bound to any symbol's
function attribute) that happened to have been stored in
print-something's function cell at some point in the past.  So, in the
second example the same function will be called, no matter in what way
print-something is manhandled in another thread.

Cheers,

Rudi