Compiled COMPILE forms at load time Bug

[Helmut Eller]

* 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