R6RS:FAQ

R6RS:FAQ


R6RSの目的は何?

R5RSまでのSchemeは、最小限のコア言語を仕様として定めておき、 実用化に必要なレイヤは各実装に任せるという方針でした。 また、最小限のコア言語は、言語の新たな機能を実験するワークベンチという 役割も持っていました (例えばcall/ccだけを仕様で定めておき、様々な 例外処理システムや並行実行システムを実装して試してみる、など)。

実験・教育用言語ならそれだけでも良かったのかもしれませんが、 Schemeを実用に使うためには膨大なライブラリを揃える必要があります。 実用を指向した多くの処理系が様々な拡張を行った結果、 処理系同士で共通して使えるライブラリを書くのが厄介になってきました。

そこで、実用的なクロス実装ライブラリを書くのに必要なインフラを 仕様に盛りこむことを第一の目的として、R6RSはデザインされました。

他に、R5RSにあったいくつかの欠点を修正するという目的もあったと 思います。

R6RSはどんなふうにして制定されたの?

R6RS:経緯と将来?参照。

R6RSを採用するSchemeはどれ?

Editorial committeeに残ったのはPLT Scheme、Chez Scheme、Scheme48の 作者なので、これらは近いうちにR6RSを採用すると思われます。 (Scheme48の2人の作者のうち、Jonathan Reesは反対票を投じましたが、 Richard KelseyがScheme48のR6RS化の予定を表明しています)。

その他のSchemeについては、今のところ「採用予定無し」か、 「部分的に採用予定(APIや構文の多くはいずれR6RSに合わせるが、R6RSが要求する エラーチェックやドメインについて完全に準拠するわけではない)」となっています。

(2007/10/29 02:02:01 PDT): Marc Feeleyが主要なScheme開発者に対して R6RSサポート予定のアンケートを取りました。 c.l.sの記事で結果が一覧できます。

じゃあSchemeは分裂するの?

見方によってYesともNoとも取れます。以下はShiroの主観的見解です。

R6RSへの準拠を言語の拠り所とするならば、Schemeはいくつかの「R6RS準拠Scheme」と それ以外の多くとに分裂することでしょう。ただし、R6RSはそれ以前のRnRSを無効に するものではありません。「R5RS準拠Scheme」というラベルはR6RS以降も有効です (すなわち、R5RS→R6RSはもともと、Common LispのCLtL1→CLtL2のような線形変化を 意図していません)。実際、R5RSとR6RSは非互換なので、R6RS Scheme処理系も R5RS互換モードを用意してゆくと思われます。

一方、R6RSを非採用とする実装も、R6RSを全否定しているわけではありません。 共通モジュールシステムや、豊富なライブラリの有用性についてはむしろ認めている 人々が多数です。揉めているのは、それらを仕様に入れるべきか否か、 そして仕様に入れるとして、現在のR6RSの文言が言語仕様として完成の域に 達しているか否か、というような点です。 正直に言って、言語マニア以外にとってはどうでもいいと言えるような詳細に こだわっていると言えなくもありません。(でもそこにこだわってしまうのが Schemerなのです)。

R6RSに賛成しなかった実装者も、共通ライブラリの重要性は認めていて、 R6RSより緩い縛り(SRFI)でそれらを整備してゆこうという動きになっています。 詳しくはERR5RSを 参照してください。

結局今でも実用プログラムはSRFIをがんがん使っているわけで、 「R5RS+R6RS互換SRFI」でプログラムが書かれるようになれば、 実質的にはこれまでと同じような状況か、むしろ互換性という面では より統一される方向に向かうんじゃないかとShiroは考えています。

R6RS準拠Schemeなら実用的なプログラムが書けるの?

上で述べたように、R6RSの目的は実用的なライブラリを書けるための インフラ作りにあります。そのためにR5RSに比べてかなり標準ライブラリが 増えていますが、それら「だけ」では実用プログラムを書くにはほど遠いですし、 そもそもそちらを指向してはいません。

実用的なプログラムを書くためには、R6RSに基づいて書かれたライブラリが 揃う必要があります。

R6RSにはどんなライブラリがあるの?

R6RS:標準ライブラリに概要をまとめます。また、全てのライブラリAPIは x:R6RSの方でちくちく入力しています。

More ...