R6RS:翻訳:Rationale:Libraries

R6RS:翻訳:Rationale:Libraries

7 章 ライブラリ

ライブラリシステムの設計は挑戦に満ち満ちている。既存の多くの処理系が「モジュールシステム」を提案しているが、そのどれもが機能や目標といった点で劇的に異なっている。本ライブラリシステムでは、プログラマが可搬性のあるコードを、書き、配布し、そして発展させていくことができることを第一の要求とした。第二の要求は、依存するライブラリが翻訳されただけの状態において、ライブラリ群を分割して翻訳できるようにすることである。これらは以下の要求に帰結する。

本ライブラリシステムでは以下のようなことは目標としない(設計段階で検討はした)。

本節ではライブラリシステムの設計において議論の対象となった側面のいくつかについて述べる。

7.1 構文

ライブラリの構文は単一のフォームであり、いくつかのヘッダに続く実際のコードを格納したフォーム群ではない。フォーム群の並びが単一のフォームよりも機械処理や自動生成に適しているかどうかは明確ではない。どちらの構文を選んでも技術的な利点があり欠点がある。R6RS で選択した単一フォーム形式には自己限定的であるという利点がある。

トップレベルプログラムとライブラリの違いは、プログラムにはトップレベルプログラムはひとつしかなく、ライブラリは複数あるということである。したがって、ライブラリ本体に関するテキストの区切りを決定し、(様々な種類のストリーム中で)他と区別しなければならないのは一般的な要請であると言える。このとき括弧を使うことは言うまでもない。

7.2 局所インポート

一部の実装のモジュールシステムでは、モジュール内の束縛を局所環境にインポートすることができる。局所インポートを使うことにより、インポートの範囲を制限し、コードのモジュール性を高め、インポートしたものに接頭辞をつけたり別名をつけたりする必要が少なくなる一方で、局所インポートの存在により、あるライブラリが依存するライブラリをヘッダ挙げられているものから精確に近似できなくなるという問題がある(局所インポートがない場合でも依存している束縛を精確に決定することはできない。これは、挙げられているライブラリであっても公開されている識別子が使用されていなかったり、environment 手続きにより、実行時に、挙げられていなかったライブラリがインポートされる可能性もあるからである)。現在は局所インポートを除外しているが、これは将来もそれを続けるということを意味するものではない。

7.3 局所モジュール

局所ライブラリや局所モジュールを持つ、すなわち、ライブラリやモジュールがトップレベルライブラリ内やトップレベルの本体部分に現れることができる実装もある。こうすることにより、ライブラリとトップレベルプログラムが一層モジュール化された部分要素に分割されるが、一方でこれは言語のスコープ規則を複雑にするものでもある。本報告書のライブラリシステムではライブラリのトップレベルからのみ他のライブラリに束縛を公開できる一方で、局所モジュールでは局所スコープ単位で他に束縛を公開することができ、識別子の束縛されている場所を特定するための規則が複雑になってしまう。現在は局所ライブラリないしモジュールを除外しているが、これは、将来これを追加することを妨げるものではない。

7.4 import 節と export 節の固定

library フォームの import 節と export 節はライブラリの構文の固定的な部分である。これにより、どの言語のどの版でその節が書かれたか特定する必要がなくなり、7.2 節で述べたような、依存するライブラリを近似する処理が単純化される。欠点は import と export 節を抽象化できないこと、すなわち、マクロ呼び出しにより生成することができないことである。

7.5 インスタンス化と初期化

展開・実行時にライブラリがどのように実体化され初期化されるべきかというのにはさまざまな意見がある。ライブラリのインスタンスはフェーズごとに区別されるべきか、それから、レベルは識別子がある特定のフェーズを使うように制約するよう宣言するべきか等々である。本報告書では、可搬性のあるライブラリを実現しつつ、実装者にかなりの裁量を認めることにしている。

キーワード定義の右辺やプログラム中のキーワード束縛フォームが syntax-rules や identifier-syntax であり、かつ、syntax-rules や identifier-syntax が別のどの文脈にも現れず、import フォームによりデフォルトの import フェーズが上書きされることのない場合、そのプログラムはフェーズ間でインスタンスが区別されるかに依存せず、識別子を使用するフェーズが識別子のレベルと一貫性を持たなくなることはあり得ないことに注意。さらに、実装側が、どのフェーズで宣言されたかに関係なく参照が任意のフェーズで許容されるという、暗黙のフェーズモデルを使用しているかぎり、識別子を使用するフェーズが識別子のレベルと一貫性を持たなくなることは決してない。

7.6 変更不能な公開要素

明示して公開した変数と暗黙に公開した変数とで代入に非対称性があるのは、暗黙裏に公開された変数については、import したライブラリが展開されるまで違反を検知できないという理由による。

7.7 ライブラリの合成名

ライブラリの名前は合成物である。これは言語の他の部分での識別子の扱いとは異なる。合成名を使うのは、構造化されたトップレベル名前空間を持ち、名前の衝突を避ける必要のある言語における経験から来たものである。単一のシンボルや文字列に階層構造を埋め込むことも確かに可能である。だがしかし、Scheme では、階層構造を文字列やシンボルにコード化するよりも、リストを使うことこそが階層構造を表すのに自然なことである。階層構造を使うことにより、一意な名前を決定する方法や、ファイルシステム中での可能な格納方式を定式化するのが簡単になる。付録の「一意なライブラリ名」を参照されたい。以上のことから、合成名の構文上の複雑さと、実装が階層構造を間違ってあつかう可能性は別として、編集者陣はリスト表現を取ることにした。

7.8 版管理

ライブラリと import 節は省略可能な版情報をあつかうことができる。これにより、ライブラリの開発履歴を反映することができ、またその一方で、ライブラリシステムを飛躍的に複雑にすることにもなっている。他の言語のモジュールシステムや、それと同様に OS レベルでの共有ライブラリにおける経験によれば、モジュールの識別のために名前だけを使ったのでは衝突が起こり、バージョン情報なしではそれを修正することができず、コードの共有性が劣ることになると考える。このような理由から、版管理をライブラリシステムの一部とすることにした。

7.9 版の異なるライブラリの扱い

実装側は同一の名前で、異なる版のライブラリが同一のプログラム中に混在することを禁止することが推奨される。一方で、これにより同一のライブラリの別の版を必要とするライブラリやプログラムの組み合わせができなくなり、ライブラリの状態を複数持つことができなくなり、Windows の DLL や Unix の共有オブジェクト等の、他の共有ライブラリシステムで起こったような問題を避けられなくなるのである。


Last modified : 2008/03/21 20:45:49 UTC