export

(export symbols &optional package)

symbols (シンボル、またはそのリスト) を package (既定では現在のパッケージ) の外部シンボルにします。これにより use-package を通じて修飾なしで見えるようになり、コロン2つではなく1つで綴られます。t を返します。defpackage の :export 節の実行時形式であり、unexport が逆操作です。

Common Lisp と同様、シンボルはエクスポート元のパッケージでアクセス可能でなければなりません。パッケージ自身のシンボルは常にアクセス可能ですが、他のパッケージがホームのシンボルはインポート済みか、use リストを通じて継承している必要があります -- 継承しているシンボルはエクスポートされると同時に存在する(インポートされた)ものになるため、このパッケージを use する側はホームのシンボルを継承します。2 種類の名前衝突も通知されます。同名の別のシンボルがすでにこのパッケージでアクセス可能な場合と、このパッケージを USE しているパッケージがすでに同名の自前のシンボル(シャドーイングでないもの)を持っている場合です。こうした失敗はいずれも捕捉可能な package-error です。unexport はシンボルを存在させたまま外部でなくするだけで、継承しているシンボルには触れません。

ここではパッケージは読み込み/コンパイル時に解決されるため (パッケージ を参照)、リテラルなトップレベル呼び出しは in-package と同様にコンパイル時に消費され、それ以降のフォームに対して効力を持ちます。これがすべてのバックエンドで動作する理由です。実行時に計算する呼び出し (実行時に構築したシンボルリスト) はインタプリタで動作し、プログラムが make-package で作ったパッケージについてはメンバーテーブルがエクスポートを記録するため、すべてのバックエンドで動作します。

export が変えるのはアクセス可能性だけなので、公開する定義の前でも後でも構いません。関数を定義してファイルの末尾で export するという Common Lisp の日常的な書き方が動作します。

export より前に書いた参照は、Common Lisp と同様にエラーです。その時点ではまだ外部シンボルではありません。

1点の相違: 最初に名前が現れた後で export されたシンボルは、コロン2つ (greeter3::hi) で表示されます。ここでは修飾子は表示時に計算されるのではなく、シンボルに保持されているためです。どちらの綴りも同じシンボルを指します。