[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
*PACKAGE* rebound by debugger
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
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
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
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
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.