Relative package names are needed for the same reason as relative pathnames, for brevity and to reduce the brittleness of absolute names. A relative package name is one that begins with one or more dots. A single dot means the current package, two dots mean the parent of the current package, and so on.
Table 2.2 presents a number of examples,
assuming that the packages named foo
, foo.bar
,
mypack
, mypack.foo
, mypack.foo.bar
,
mypack.foo.baz
, mypack.bar
, and mypack.bar.baz
,
have all been created.
relative name | current package | absolute name of referenced package |
---|---|---|
foo | any | foo |
foo.bar | any | foo.bar |
.foo | mypack | mypack.foo |
.foo.bar | mypack | mypack.foo.bar |
..foo | mypack.bar | mypack.foo |
..foo.baz | mypack.bar | mypack.foo.baz |
...foo | mypack.bar.baz | mypack.foo |
. | mypack.bar.baz | mypack.bar.baz |
.. | mypack.bar.baz | mypack.bar |
... | mypack.bar.baz | mypack |
Additional notes:
cl-user
is nickname of the common-lisp-user
package.
Consider the following:
(defpackage :cl-user.foo)
When the current package (the value of the variable *package*
)
is common-lisp-user
, you might expect .foo
to refer to
cl-user.foo
, but it does not. It actually refers to the non-existent
package common-lisp-user.foo
. Note that the purpose of
nicknames is to provide shorter names in place of the longer names
that are designed to be fully descriptive. The hope is that
hierarchical packages makes longer names unnecessary and thus makes
nicknames unnecessary.
foo.bar..baz
does not mean foo.baz
– it is
invalid. (Of course, it is perfectly legal to name a package
foo.bar..baz
, but cl:find-package
will not process such
a name to find foo.baz
in the package hierarchy.)