Function PROVIDE, REQUIRE
provide module-name => implementation-dependent
require module-name &optional pathname-list => implementation-dependent
module-name - 文字列指定子
pathname-list - nilか、 パス名指定子の空ではないリスト。 デフォルトはnil。
provideは*modules*が保有しているリストに、 そのような名前がまだ存在していないときに module-nameをそのリストに追加します。
requireは*modules*が保有するリスト内に module-nameが現れているかテストします。 もし現れているとき、requireは即座に返却します。 それ以外のとき、 次に示すようにファイルの集合を適切にロードするよう試みます。 pathname-listの引数について、 nilではなくパス名のリストを指定しているとき、 左から右の順番でロードを行います。 もしpathname-listがnilのとき、 実装依存の仕組みにより module-nameという名前のモジュールを ロードするような仕組みが起動されます。 もしそのようなモジュールがロードできなかったとき、 型errorのエラーが通知されます。
両関数は、module-nameの存在をテストするときに string=を使用します。
;;; これは移植不可能なREQUIREの使い方を示しています。
;;; なぜなら実装依存のファイルロードメカニズムだからです。
(require "CALCULUS")
;;; これはリテラルな物理パス名のため
;;; 移植不可能なREQUIREの使い方です。
(require "CALCULUS" "/usr/lib/lisp/calculus")
;;; 移植可能な使い方のフォームとして論理パス名を指定しており、
;;; どこかで適用可能な変換が定義されているものとします。
(require "CALCULUS" "lib:calculus")
;;; 他の移植可能な使い方のフォームとして変数か
;;; テーブルの検索関数によるパス名の決定が挙げられます。
;;; これもまたどこかで初期化する必要があります。
(require "CALCULUS" *calculus-module-pathname*)requireによって取られる特定の行動は、 provideの呼び出しによって （または一般的に*modules*の値の変更によって） 影響します。
module-nameが文字列指定子ではなかったとき、 型type-errorのエラーが通知されるべきです。
もしrequireが ファイルシステムとの相互処理をしている間に 要求された処理に問題が生じて失敗したとき、 型file-errorのエラーが通知されます。
もしpathname-listの何かのパス名が ワイルドカードのパス名を指定した指定子であったとき、 型file-errorのエラーが通知されるかもしれません。
*modules*, 19.1.2. ファイル名としてのパス名
もしモジュールがひとつのパッケージに含まれているとき、 慣習的にはパッケージとモジュールの名前は同じになります。