* Raymond Toy [2010-03-15 22:49+0100] writes:
The code that does this is define-function-name in proclaim.lisp. If the name is an accessor-for, then undefine-structure is called. The comment for undefine-structure says it's supposed to blow away all compiler info and undefining all associated functions.
Now I see. It looks like undefine-function-name would be more adequate or just fmakunbound.
Yeah, that would work too. I guess we need to decide what we really want to happen if you try to redefine a structure accessor. Undefining the structure seems a bit heavy-handed, especially since we just warn afterwards instead of signaling at least a continuable error. We could just allow the redefinition and assume (or perhaps check) that the new function at least takes the same arguments.
For (defun some-existing-accessor ..) I'd like to see a warning at compile time--if it can be done easily. At load time, a cerror if the whole structure gets removed; no warning if only the accessor gets overwritten. We have already definition locks which can be used for more delicate accessor names.
It's a bit troubling that c:%%defun does so much more than a simple (setf (fdefinition ..)). If a user calls (setf (fdefinition ..))
%%defun doesn't seem like so much to me; it looks like it's just setting up the compiler info db with the appropriate info.
directly the various bits in the info db are not cleaned out.
That's probably an oversight; we can add another *setf-fdefinition-hook* to clear out the info db or update the info db based on what ever information we have about the new fdefinition function.
On one side (setf (fdefinition ..)) should delete/overwrite the stuff that a previous %%defun left in the info db. On the other hand, if the user wants to update the info db he can and should use defun. Hmm.. actually I prefer the latter, i.e. what CMUCL does currently. Helmut