*PACKAGE* rebound by debugger

[Barry Margolin <barmar@THINK.COM>]

    Date: Tue, 30 Aug 88 12:23 CDT
    From: Cohen@mcc.com (Richard M. Cohen)


	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 solution Chris Lindblad worked out for this, and which we are also
using here at TMC, is to have SI:READFILE-INTERNAL and
SI:LOADING-BIN-FILE-INTERNAL bind the standard value of *PACKAGE* to its
current value around the load, i.e. they do

	;; PACKAGE is already bound to the package in the file attribute list 
	(LET ((SAVED-PACKAGE PACKAGE))
	  (STANDARD-VALUE-LET ((PACKAGE (STANDARD-VALUE 'PACKAGE)))
	    (LET ((PACKAGE SAVED-PACKAGE))

This doesn't need the -PERMISSIVELY versions you describe, because the
standard value is always being bound to a standard value, which must
have already passed the validation function (unless it is a very
context-sensitive function, which is a BAD idea).

    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.

Your version does do this better.  However, most of our software uses
IN-PACKAGE (all the CM system software is supposed to be portable, and
we do relatively little Symbolics-specific application software), so the
ECO version comes pretty close for us.

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
0    2loaded?)0 2Note that ZMACS does this for the interactive environment when
    you suspend.]

0Probably.  My users never complained about this because all our software
is in CL syntax and base 10.

                                                barmar