On 3/15/10 1:58 PM, Helmut Eller wrote:
* Raymond Toy [2010-03-15 16:18+0100] writes:
On 3/15/10 10:45 AM, Helmut Eller wrote:
* Raymond Toy [2010-03-15 15:01+0100] writes:
On 3/12/10 11:45 AM, Helmut Eller wrote:
* Raymond Toy [2010-03-12 12:35+0100] writes:
So COMPILE has silently zapped the structure. We should probably print he warning for this too.
Yes, definitely. Also for this:
(defstruct xyz a) (setf (fdefinition 'xyz-a) (lambda () 42))
I added a hook to *setf-fdefinition-hook* to check for this case. Works ok, but now I can't compile clx/depdefs.lisp. CMUCL complains about redefining reply-size and buffer-lock which are slot accessor functions. But I haven't figured out from the code where the redefinition is coming from.
Also, consider this:
(defstruct abc a b c) (defun abc-a () 42)
CMUCL undefines the structure, but
CMUCL undefines the structure? That seems a bit aggressive. I think it should only delete the (c:info function info 'abc-a) entry if that's not done yet. The compiler uses that to recognize "known" functions.
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.
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. Ray