Should `compile-op` bind `*package*` to CL-USER?
I'm working with some packages that do not `(:use :cl)`, and compiling some systems which have bare, non-package-prefixed `defpackage` forms. (Sadly, I haven't convinced people to use `uiop:define-package` yet, as the SBCL distributed version doesn't have `:local-nicknames` support :disappointed: .) When my REPL is `in-package :SOME-PACKAGE-THAT-DOESNT-USE-CL`, doing `asdf:load-system` to compile and load a file like:
```
(defpackage #:foo
;; some defpackage clauses
)
(in-package #:foo)
;; some code or whatever
```
fails with an error, because the `defpackage` form reads as `some-package-that-doesnt-use-cl::defpackage`, which is assumed to be a call to an undefined function, `#:foo` is treated as a read from a variable, and everything falls apart. What's worse, I can't just `in-package :cl-user` at the repl and then re-run the `asdf:load-system`, because the compiled fasls are cached, so I have to change back to a cl-using package and then `asdf:load-system` with `:force t` or `:force :all`.
The obvious solution, in my mind, is to have the `perform compile-op lisp-source-file` method locally bind `*package*` to `cl-user`, with the assumption that either:
- The file intends to use `in-package` to specify the package it actually should be in, or
- The file expects to be compiled in the default package, i.e. `cl-user`.
Probably this local binding should be put in place outside of `call-with-around-compile-hook`, so that it's still possible to use `:around-compile` to locally bind `*package*`. (I hope no one does that, though. Ew.)
Would this break anything?
issue