Bug report: Loading a FASL into a package which doesn't import SETQ

[Robert Munyer]

>> To be honest, I think the problem is with the FASL generator:
>> it should be prefixing (all) symbols with their packages when
>> that's required to load the FASL back into a similar environment.

Yes.  Here is some debug code:

----------------
; put this before COMPILE-FILE's definition:

(defvar cl-user::*setq-needs-prefix* nil)

; put this around COMPILE-FILE's body:

(let ((cl-user::*setq-needs-prefix* (not (eq (find-symbol "SETQ") 'setq))))

  )

; put this before WRITE's definition:

(defvar cl-user::*setq-needs-prefix* nil)

; put this before WRITE's body:

(when (and cl-user::*setq-needs-prefix* (eq (find-symbol "SETQ") 'setq))
  (break "SETQ needs package prefix"))
----------------

Backtracing within that BREAK points a finger at this line in
COMPILE-FROM-STREAM:

            (let ((*package* (find-package '#:cl))

If I add one semicolon:

            (let (;(*package* (find-package '#:cl))

then all of my own tests pass, though I haven't tried the full suite.

It's conceivably possible that _all_ of the manipulation of *PACKAGE*
that happens during COMPILE-FILE could be removed, because the user is
already required to have *PACKAGE* set correctly when invoking LOAD.