The Symbolics ECO tape, which some of us picked up at SLUG'88, included
the much-requested fix to IN-PACKAGE that sets the standard value of
*PACKAGE*, so that the debugger will use the package of the file being
read in. However, this introduced a bug, because the standard value
mechanism includes a mechanism for checking the validity of new values
for the variables. In the case of *PACKAGE*, it checks that the new
value is actually a package, it is unlocked, and that it inherits from
one of the reasonable global packages (the value of
SI:*REASONABLE-PACKAGES*, initially ZL, CL, and SCL). This is a
reasonable check when setting the interactive package for the user, but
this was causing IN-PACKAGE to go into the debugger when setting the
package for a file being loaded, if the file was in a package that
doesn't :USE any other packages (we have a few of these in our
software).
I have changed the new definition of IN-PACKAGE to simply
print a warning when this error occurs, rather than go into the
debugger. The standard value of *PACKAGE* will still not be changed, so
the debugger will still revert back to the old package in such cases,
but the current value will be set.
Locally, I made this change by modifying the function definition.
However, I think the following advice is equivalent to what I did, and I
don't have to worry about publishing Symbolics copyright code on the
net.
(si:advise-permanently (:within in-package si:setq-standard-value-2)
:around warn-instead-of-error nil
(condition-case (cond)
:do-it
(si:invalid-standard-value
(warn "~A~&The current value of ~S will be updated, but the standard value will not be changed.~%"
cond '*package*))))
barmar