I've pretty much come to the conclusion that the way I'd like to handle
the current problem of resignaling PACKAGE-LOCK-VIOLATIONs from the
1) Don't Do It. Document the fact that compiler handles package lock
violations and code at fault signals a runtime PROGRAM-ERROR.
2) Provide a new operators
macro WITH-DISABLED-PACKAGE-LOCKS (&key symbols packages all) &body body
macro WITH-ENABLED-PACKAGE-LOCKS (&key symbols packages all) &body body
that are analogous to the DISABLE/ENABLE-PACKAGE-LOCKS declarations,
except that they operate in the dynamic scope, and can control package
locks on symbol, package, and global granularities. They also interact
with the declarations in a documented manner.
3) New declarations
DISABLED-PACKAGE-LOCKS &key symbols packages all
ENABLED-PACKAGE-LOCKS &key symbols packages all
that are just like the old DISABLE/ENABLE-PACKAGE-LOCKS declarations,
except that they can also manage other then symbol granularities.
4) Deprecate WITHOUT-PACKAGE-LOCKS, WITH-UNLOCKED-PACKAGES,
ENABLE-PACKAGE-LOCKS, and DISABLE-PACKAGE-LOCKS, retairing them
completely after couple of releases.
How does this sound?
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."