Re: COMPILE regression in Apr 2010 snapshot (?)

On 4/26/10 6:16 AM, Madhu wrote:
> * Raymond Toy <[email protected]> :
> Wrote on Sun, 25 Apr 2010 23:29:54 -0400:
>
> | 
> |
> | We now have:
> |
> | (PROGN
> |   (DECLAIM (SPECIAL ABC))
> |   (UNLESS (BOUNDP 'ABC)
> |     (SETQ ABC NIL))
> |   (SETF (DOCUMENTATION 'ABC 'VARIABLE) '"abc")
> |   (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE)
> |     (SETF (INFO VARIABLE INTL:TEXTDOMAIN 'ABC) NIL))
> |   (LISP::SET-DEFVAR-SOURCE-LOCATION 'ABC (C::SOURCE-LOCATION))
> |   'ABC)
> |
> | I do not understand it, but that (setf info) causes the problem.  When
> | that is removed, cmucl behaves as it used to.  I don't understand why
> | that would cause the macro to be compiled again.
>
>
> My report may have been misleading: I do not think that macro is being
> compiled again, it just looks that way from the notes that CMUCL prints.
>
> I have not looked at the CMUCL code yet, but I my guess (without looking
> at any commits) is that this is more likely related to some source
> recording changes that may have been introduced.
>   
AFAIK, there have been no changes to source recording.

I think what is happening is that the eval-when for the (setf info) form
is causing the compiler to compile the top-level form.  It creates a
component name by looking up the source file and finds
frob-kevals-string form and uses that as the component name.  That's
what gets printed which makes it look like it's compiling
frob-keyvals-string again.  But it's really just compiling the defvar.

When the (setf (info ...)) is replaced by a (lisp::%%defvar ...) where
the new function %%defvar just calls (setf (info ...) ..), the printed
messages are much nicer.

So, I think it's not really a problem. Rather it's just a poor choice of
component name by the compiler.   So using %%defvar is a possible solution.

Ray