SRFIを書く/採用する理由

まだドラフトにもなっていないが新しいSRFIを提出した。ぶっちゃけ大したものではないが、あると便利系のものである。実装はR7RS+既存のSRFIで行ったのだが、これがまた面倒であった(多少SRFIを書く理由にかかる)。一つの処理系のみを使ってる、もしくは手元に過去の資産としてある程度のコードがあるという状態であればSRFIは特に必要ないだろう。ただ、それだと非常に面倒なのである。ソート手続き一つを取ったとしても、たとえ20行もあれば書けるとはいえ、毎回書きたくはない。開発効率を見れば、よく使うものは処理系がサポートしているべきである。そう、私がSRFIを書くもしくは採用する一つの理由はあれば便利だからである。特に最近のR7RS-large絡みのSRFIはScheme用ライブラリの拡充に近い部分があり、あると便利なのである。

私はちょいちょいポータブルなライブラリを書く。 R6RSかR7RSかはそのときの気分次第ではあるが。最近はR7RSの方が多い気がする、処理系の更新があるから。よく使うR6RS処理系(Mosh、Ypsilon)は更新とまってるんだよねぇ、はぁ・・・。ポータブルなものを書く理由は特にない、あるとすれば名前を売るか自己満足くらいだろう。Schemerが増えてSagittariusへのフィードバックが多くなるといいなぁとかも考えてはいるが、期待はしていない(正直特に反応もないし)。これはポータブルなものに限った話ではないのだが、ライブラリを書く際に部品が足りていないと非常に辛い。例えば優先度つきキューを考えてみる(最近適当なのを書いたのだ)、こんな超が付くほど有名なデータ構造は標準もしくは準標準でサポートされていてほしいと思うのが多少なりともプログラムを書いた人間なら思うだろう(学習用とかは除く)。しかし、残念ながらSchemeにはどちらにもないのである。

なければその場で書いてもいいだろう、 実際適当な実装であれば50行もあれば書けてしまうのだ。問題はそれがこれか何万回と続く可能性があることだ。誰もが使う可能性があるデータ構造、アルゴリズムというものは裏を返せば(返さなくても)自分もよく使うのである。R5RS以前のSchemeはモジュールという概念がなく、そういったものを標準の範囲内でまとめておくことができなかったが、R6RS以降はライブラリがあるのだ、使わない手はない。

もう一つ理由がある。インターフェースの統一である。例えばスレッド関連のSRFIとしてSRFI-18があるのだが、不思議なことに採用している処理系はそんなに多くない。POSIXスレッドモデルを採用している処理系であれば互換レイヤを書くのはそんなに難しくないのだが、世の中そんなに甘くない。私がよく使うR6RS処理系、MoshとYpsilon、はMutexすらユーザに見せていない。 そうすると同期を必要とするライブラリを書くのが非常に面倒になる(それらをサポートしないという手ももちろんあるが・・・)。こうなったときに処理系側にサポートを強要することが可能な一つの手段としてSRFIがあると思っている。

例えばSRFI-1を考えてみる。リスト処理に特化したこのSRFIは数多くの処理系がサポートしている(ポータブルに書けるというのは置いておくとしてだ)。多くの処理系がサポートしているデファクトSRFIというのは他の処理系もないがしろにしないだろう(個人的感想)。例えばSagittariusは元々SRFI-25とSRFI-78をサポートしていなかったが(特にSRFI-78はSRFI-64とコンセプトが似ているので)、ユーザからのフィードバックでサポートするようになった(実装まで送られてきたのではしないわけにもいくまい)。こういう経験から、あるSRFIが幅広く使われるようになれば、例えポータブルなものが使えない処理系でも、サポートされるのではないかという期待が持てるのである(その処理系が継続的に開発されてればではあるが・・・MoshもYpsilonも数年新しいリリース出てないなぁ・・・)。

特に何のオチもないのだが、終わり。