Compiled COMPILE forms at load time Bug

[Helmut Eller]

* 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.

It's a bit troubling that c:%%defun does so much more than a simple
(setf (fdefinition ..)).  If a user calls (setf (fdefinition ..))
directly the various bits in the info db are not cleaned out.

>> I don't know if (setf abc-a) still works if the info entry for abc-a is
>> cleared.
>>
>>   
>>> (defstruct abc a)
>>>
>>> produces an error about incompatibly redefining the structure.
>>>     
>> That seems totally OK to me.
>>   
> Well, I was expecting that if we undefined the structure, then there
> would be no information about the structure, and hence didn't exist.  
> But perhaps that can't be completely true if there are already structure
> objects of that type.

Hmm... looks like undefine-structure doesn't delete the 
(info type class ..) bit which still points to the defstruct description.

Helmut