Package locks have now been merged to the CVS HEAD.
Summary of open issues:
* Should package locks be enabled by default? Currently they
aren't, but #lisp consenus seems to be that they should.
Will get more testing and feedback on the interface.
Attractive NEWS message:
12:37 <Xophe> "minor incompatible change: code not obeying clhs
22.214.171.124.2 is now broken in a more definitive way"
Joe User is less likely to twiddle with *features* (I guess),
but would definitely benefit from the safety net provided by
Interface changes will hurt users more -- though only if they are
either actively using package locks for their own code or are doing
something nasty to COMMON-LISP or SB-* packages (like McCLIM). ...and
there are both "not quite happy with this" and "will change somewhat"
issues with the interface (summarized later).
* Known interface issues
The :implement option to DEFPACKAGE, as discussed earlier is not
optimal as far as names go. Furthermore, I'd like it to be also
usable with symbol-granularity, eg. (:implement-symbols foo:bar
bar:quux). And if the :implement option is renamed, so should
all the implementation-package operators (and the whole concept,
There should probably be a (unlock-package foo bar) declaration
in addition to the DISABLE/ENABLE-PACKAGE-LOCKS, or the latter
should maybe accept strings as well and for them disable package
locks for the named packages. There should possibly also be
a declaration to disable all package locks for the lexical scope.
Compile-time package lock violations should probably result
in code that signals a program-error instead of interrupting
the compilation with an option to continue. The only question
about this is whether or not users should be able to do something
(handler-bind ((sb-ext:package-lock-violation #'maybe-continue))
* Outstanding FIXMEs:
SBCL doesn't currently compile cleanly under SBCL-style package
locks. There are a few DEFVARs of symbols in the COMMON-LISP package
that are done under the host lisp, and some COMMON-LISP symbols
rebound as local macros as well. To remedy this SBCL when building
under an SBCL with package locks currently unlocks all packages,
which is unsightly to say the least.
The inital package-lock sanitation of at least SB-GROVEL and
SB-SIMPLE-STREAMS is not all that elegant, and should be fixed.
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."