システム
lompi
Loment のパッケージマネージャ。ツールチェインに同梱されるが、loment の
サブコマンドではない —— 別のプログラムで、独自のバージョンと独自の
ガイドを持つ。
ライブラリとはディレクトリである
学ぶべきマニフェスト形式も、それを書くための第二の言語もない。ライブラリとはLoment ファイルでいっぱいのディレクトリであり、パッケージシステムが普通は発明する三つの ものは、すでに言語の中にあるか、そこから導かれるか、生成されるかである:
エクスポート —— すでに言語の中にある
pub。新たに宣言すべきものも、ソースと同期させ続けるものもない。
依存 —— use の行
依存リストはない。解決器は、ソースがすでに持っているインポートを 読む。だから「宣言されているが使われていない」と「使われているが宣言されていない」は、 それが生み出しうるエラーですらない —— それらは存在しない状態である。
同一性 —— 再帰的な内容ハッシュ
パッケージの同一性は、自分自身のソースと、それが依存するすべてのものの 同一性から、最後まで辿って計算される。パッケージ自身のファイルだけをハッシュするのは 誤りであろう。同じソースでも、異なる依存に束縛されれば別のものであり、誤って統合されて しまう。
最後のひとつが、複雑さのあるカテゴリを丸ごと取り除く。バージョン範囲の言語も、解決器も、 解決の衝突もない。あるライブラリの二つのバージョンは単に二つの同一性であり —— そしてそれらは共存できるからだ。
ラベルファイルは Loment である
パッケージは .lomp ファイルを運んでよい。それは通常の意味でのマニフェストでは
ない: それはLoment ソースで、報告するのはせいぜい名前とバージョンであり、
依存の節を持たない —— そもそも依存はファイルに宣言されたことがないからだ。省けば、
ディレクトリ名がパッケージ名になる。
その中のバージョン番号は、人間のためのラベルである。機械はそれを使って何かを選んだり しない。内容ハッシュがすでにそれを済ませている。
なぜ通常の設計ではないのか
ライブラリはバイナリとして出荷できない
ジェネリクスはインスタンス化ごとに単相化されるので、コンパイラは何を生成するか決める ためにソースを見なければならない。コンパイル済みの塊とヘッダ、という選択肢はない —— ひとつのインターフェイスの二つの記述を歩調を合わせて保つ、という種類の問題も同様に ない。
レジストリサービスはない
拡張点はディスク上のファイルである。名前が何を意味するかを決める中央サーバーはない。
loment の一部ではない
lompi はツールチェインと並んでインストールされ、PATH 上に
あるが、コマンドの面の外に留まる —— loment help はそれを載せず、
loment がそれに転送することも決してない。その分離は意図的で、
強制されている。
今日受け取るもの。Loment のソースライブラリ。実在の C ライブラリには
choose hosted を通じて到達できる —— ビルドでそのライブラリを名指しする ——
が、それらはまだインストール可能な依存ではない。外部のライブラリをインストール
することこそ、パッケージマネージャの次のリリースの役目である。