通常一个符号在读入时就被 interned 至当前的包里面了。函数 symbol-package 接受一个符号并返回该符号被 interned 的包。

(symbol-package 'sym)
#<Package "COMMON-LISP-USER" 4CD15E>

有趣的是，这个表达式返回它该返回的值，因为表达式在可以被求值前必须先被读入，而读取这个表达式导致 sym 被 interned。为了之后的用途，让我们给 sym 一个值:

> (setf sym 99)
99

现在我们可以创建及切换至一个新的包：

> (setf *package* (make-package 'mine
                                :use '(common-lisp)))
#<Package "MINE" 63390E>

现在应该会听到诡异的背景音乐，因为我们来到一个不一样的世界了： 在这里 sym 不再是本来的 sym 了。

为什么会这样？因为上面我们设为 99 的 sym 与 mine 里的 sym 是两个不同的符号。 要在用户包之外参照到原来的 sym ，我们必须把包的名字加上两个冒号作为前缀：

99

所以有着相同打印名称的不同符号能够在不同的包内共存。可以有一个 sym 在 common-lisp-user 包，而另一个 sym 在 包，而他们会是不一样的符号。这就是包存在的意义。如果你在分开的包内写你的程序，你大可放心选择函数与变量的名字，而不用担心某人使用了同样的名字。即便是他们使用了同样的名字，也不会是相同的符号。

通常使用两个冒号作为包的前缀也是很差的风格。这么做你就违反了包本应提供的模块性。如果你不得不使用一个双冒号来参照到一个符号，这是因为某人根本不想让你用。

通常我们应该只参照被输出 ( exported )的符号。如果我们回到用户包里，并输出一个被 interned 的符号，

MINE> (in-package common-lisp-user)
#<Package "COMMON-LISP-USER" 4CD15E>
> (export 'bar)
T
> (setf bar 5)
5

我们使这个符号对于其它的包是可视的。现在当我们回到 mine ，我们可以仅使用单冒号来参照到 bar ，因为他是一个公开可用的名字：

#<Package "MINE" 63390E>
MINE> common-lisp-user:bar
5

通过把 bar 输入 ( import )至 mine 包，我们就能进一步让 mine 和 user 包可以共享 bar 这个符号：

在输入 bar 之后，我们根本不需要用任何包的限定符 (package qualifier)，就能参照它了。这两个包现在共享了同样的符号；不可能会有一个独立的 mine:bar 了。

要是已经有一个了怎么办？在这种情况下， import 调用会产生一个错误，如下面我们试着输入 sym 时便知：

MINE> (import 'common-lisp-user::sym)
Error: SYM is already present in MINE.

另一个方法来获得别的包内符号的存取权是使用( use )它：

MINE> (use-package 'common-lisp-user)
T

现在所有由用户包 (译注: common-lisp-user 包）所输出的符号，可以不需要使用任何限定符在 mine 包里使用。(如果 sym 已经被用户包输出了，这个调用也会产生一个错误。)

含有自带操作符及变量名字的包叫做 common-lisp 。由于我们将这个包的名字在创建 mine 包时作为 make-package 的 :use 参数，所有的 Common Lisp 自带的名字在 mine 里都是可视的:

#<Compiled-Function CONS 462A3E>

在编译后的代码中, 通常不会像这样在顶层进行包的操作。更常见的是包的调用会包含在源文件里。通常，只要把 in-package 和 defpackage 放在源文件的开头就可以了，正如 137 页所示。

这种由包所提供的模块性实际上有点奇怪。我们不是对象的模块 (modules)，而是名字的模块。

每一个使用了 common-lisp 的包，都可以存取 cons ，因为 common-lisp 包里有一个叫这个名字的函数。但这会导致一个名字为 cons 的变量也会在每个使用了 common-lisp 包里是可视的。如果包使你困惑，这就是主要的原因；因为包不是基于对象而是基于名字。