*PACKAGE* rebound by debugger

["Richard M. Cohen" <Cohen@MCC.COM>]

    Date: Fri, 27 May 88 18:54 EDT
    From:     SWM@SAPSUCKER.SCRC.Symbolics.COM (Scott McKay)

	Date: Fri, 27 May 88 15:00 EDT
	From:     Stever@IVORY.S4CC.Symbolics.COM (Stephen Robbins)

	    Date: Fri, 27 May 88 13:19 EDT
	    From:     barmar@Think.COM (Barry Margolin)

	    The complaint is that when you get an error during loading a file,
	    *PACKAGE* is generally bound by the debugger to something like CL-USER,

	    The same thing also happens if the user uses IN-PACKAGE interactively to
	    change his default package rather than the :Set Package command or
	    ZL:PKG-GOTO.

	This also bit me for many, many months.  Programming only in Common Lisp, I
	used 1in-package0 for package switches in my source files.  I'd love to see the
	debugger 2not0 reset the package.

    All you, and probably Barmar too, are arguing for is having 1in-package
0    behave like 1pkg-goto0.  I see nothing wrong with that.

Well, I just got hit by this fix.  So apparently it got included in
the ECO tape.

The problem is that this fix makes IN-PACKAGE always change both the
current value of *PACKAGE* and the standard binding of *PACKAGE*
(assuming the new package passes the validation function).  This
happens even if the IN-PACKAGE call is only changing a dynamic binding
of *PACKAGE*.  Thus, the effect of IN-PACKAGE on si:*standard-bindings*
will outlive the dynamic effect on the binding of *PACKAGE*.

(Specifically, I had a file that contained a call to IN-PACKAGE.  When I
saved a world after loading that file, the world "mysteriously" booted
into the "standard" package declared for loading that file!)

The original objections were to the debugger rebinding *PACKAGE* when
you break loading a file.  People wanted the debugger to leave *PACKAGE*
unchanged (unless the value of *PACKAGE* was unsuitable -- presumably
something failing the validation function for the standard-value of
*PACKAGE*).  The desired behavior can be obtained by using a dynamic
binding of the standard-value of *PACKAGE* while loading a file.

2[New question:  Should other values bound via file attributes be
treated similarly by the debugger?  (I.e., should variables, such as
*READTABLE* and *PRINT-BASE* be left to those in use by the file being
loaded?)0 2Note that ZMACS does this for the interactive environment when
you suspend.]

0Specifically:

LOAD calls Si:READFILE-INTERNAL or Si:BIN-LOAD-FILE-INTERNAL to do the
actual loading.  Both of these functions bind PACKAGE once explicitly,
and may rebind it via a PROGV binding based on FS:FILE-ATTRIBUTE-BINDINGS.
Often, but not always, a file's attributes list will specify a package.

Both of these bindings bind *PACKAGE* dynamically, and they should also
bind the standard value of *PACKAGE* dynamically.  This could be done
via SI:STANDARD-VALUE-LET and SI:STANDARD-VALUE-PROGV, expect that these
functions both barf if the value fails the validation test.

So, a better fix would be:

(1) Define two new functions:	SI:STANDARD-VALUE-LET-PERMISSIVELY, and
				SI:STANDARD-VALUE-PROGV-PERMISSIVELY.

They always bind variables dynamically, but only bind the
standard-values if the new value passes the validation function.

(2) Use SI:STANDARD-VALUE-LET-PERMISSIVELY and
SI:STANDARD-VALUE-PROGV-PERMISSIVELY in SI:READFILE-INTERNAL and
SI:BIN-LOAD-FILE-INTERNAL.

Considering the "new question", we note that:

(a) Using STANDARD-VALUE-PROGV-PERMISSIVELY results in treating all of the
file-attribute values as standard-values for the duration of the load
(i.e., the debugger won't rebind them).

(b) Just using STANDARD-VALUE-LET-PERMISSIVELY for *PACKAGE* (and
leaving PROGV for file-attributes) would support the milder solution of
only preserving the package when entering the debugger.