future SBCL releases are possible, even expected: the concept of
``implementation packages'' and the associated operators may be renamed;
more operations (such as naming restarts or catch tags) may be added to
-the the list of operations violating package locks.
+the list of operations violating package locks.
@menu
* Package Lock Concepts::
spurious package-lock-violations at runtime even if the packages are
unlocked.
-In practice all this means that package-locks have a neglible
+In practice all this means that package-locks have a negligible
performance penalty in compiled code as long as they are not violated.
@node Operations Violating Package Locks
Re-enables package locks affecting the named symbols during compilation
in the lexical scope of the declaration. Enabling locks that were not
-first disabled with @code{sb-ext:disable-package-locks} declararion, or
+first disabled with @code{sb-ext:disable-package-locks} declaration, or
enabling locks that are already enabled has no effect.
@end deftp