*PACKAGE* rebound by debugger

[Scott McKay <SWM@sapsucker.scrc.symbolics.com>]

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

    There's a piece of behavior of the Genera that has been bothering many
    users here for a long time.  We've been complaining about it since at
    least 7.0.  We developed a kludgey patch around it, but since we just
    discovered that the patch didn't work in 7.2 (all the references to
    ZL:PACKAGE had to be changed to *PACKAGE*), they've started bugging me
    about it.  I'm CCing SLUG to find out whether other users find this
    behavior obnoxious.

    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,
    rather than being left bound to the package the file was being loaded
    into.  The files have packages in their attribute lists and also contain
    IN-PACKAGE as their first form.

It's intentional that the Debugger do this.  The idea is that the
Debugger and break loops shuold run in a known and predictable
environment.  If you want to change *PACKAGE* in a way that causes the
Debugger to not re-bind it, use (SETF (SYS:STANDARD-VALUE XXX) YYY).
It turns out the :Set Package and ZL:PKG-GOTO do this as part of their
contract.

    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 automatic rebinding of *PACKAGE* makes it a pain to debug, because
    you have to use package prefixes to reference all the variables of the
    program that failed.  IN-PACKAGE is the standard Common Lisp function
    for changing the default package.

You could just type :Set Package in the Debugger.

    The workaround patch some of our users use is:

    (setq si:*standard-bindings*
	  (delete '*package* si:*standard-bindings* :key #'car))

    (si:advise-permanently si:setq-standard-value-2 :around package-hack nil
      (if (and (eq (car arglist) '*package*)
	       (packagep (cadr arglist)))
	  (setq *package* (cadr arglist))
	  :do-it))

    Is this behavior intentional or have you just not gotten around to
    fixing it?  I've tried to justify it to my users, with arguments like
    "it's trying to pretend that default packages are associated with I/O
    streams" (I've long believed that reader/printer options such as
    *READ-BASE*, *PRINT-ARRAY*, and *READTABLE* should be able to be
    specified when opening a character stream, and have those be the
    defaults when doing I/O to the stream), but they don't buy it.  All they
    see, and I can understand their point, is that they need to debug a
    program that was loading into the *LISP package, and they've been pulled
    arbitrarily into the CL-USER package.