Re: Compiled COMPILE forms at load time Bug

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