Previous: Changes to cl:find-package
, Up: Compatibility with ANSI Common Lisp [Contents][Index]
cl:find-package
Even without the modifications to cl:find-package
, authors need
not avoid using relative package names, but the ability to reuse
relative package names is restricted. Consider for example a module
foo which is composed of the my.foo.bar and
my.foo.baz packages. In the code for each of the these packages
there are relative package references, ..bar and ..baz.
Implementations that have the new cl:find-package
would have
:relative-package-names on their *features*
list (this is the case of CMUCL releases starting from 18d). Then,
in the foo module, there would be definitions of the
my.foo.bar and my.foo.baz packages like so:
(defpackage :my.foo.bar #-relative-package-names (:nicknames #:..bar) ...) (defpackage :my.foo.baz #-relative-package-names (:nicknames #:..baz) ...)
Then, in a #-relative-package-names implementation, the symbol my.foo.bar:blam would be visible from my.foo.baz as ..bar:blam, just as it would from a #+relative-package-names implementation.
So, even without the implementation of the augmented
cl:find-package
, one can still write Common Lisp code that will
work in both types of implementations, but ..bar and
..baz are now used, so you cannot also have
otherpack.foo.bar and otherpack.foo.baz and use
..bar and ..baz as relative names. (The point of
hierarchical packages, of course, is to allow reusing relative package
names.)
Previous: Changes to cl:find-package
, Up: Compatibility with ANSI Common Lisp [Contents][Index]