Gauche:Translation:Devlog:R7RSサポート
(原文: R7RS support)
公式発表はまだですが、 R7RS が承認されているようです。 わーい! それの実現のために長くつらい仕事をしてくれたワーキンググループメンバーに多謝。
時間的制約が主因で R6RS でしたようにはたくさんの議論に参加できませんでしたが、もうひとつの理由は R6RS の開発中に感じたものと違ってドラフトにおおよそ満足していたからです。
私は R6RS を嫌いではありません。 いくつかは私の好きな部分 (例えば I/O 機構) もあり、 R7RS-large はそれらのようになることを期待しています。
R6RS は野心的過ぎたと思います。 私見ですが、早まって導入された部分の抜け穴を全て塞ぐことを懸命に試みていました。
R7RS-small は完璧ではありません。 でも、 R5RS の最大の欠点のいくつかを修正していて、充分な進歩です。
残りの欠陥を修正するためには、もっと活発な実装で採用されている準標準 SRFI を待つ方が良いと思います。
R7RS が SRFI のいくつかで行ったように、標準は後回しで良いでしょう、デファクトと実績ある方法との成文化にすぎません。
* * *
Gauche の 開発中の HEAD は既に R7RS をいくらかサポートしています。 gosh -r7 として gosh を呼出したら、 R7RS REPL モードに入ります。 今のところ、 R7RS-small のライブラリを暗黙のうちにインポートします。 また、 define-library フォームを含むファイルをロードすることが出来ます。
しかしながら、ポータブルな R7RS のライブラリをロードするためにはまだかなり準備ができていない。 最大の障害は、字句構文です。 文字列とシンボル中の \xNN; 方式エスケープは、下位互換性の問題故にまだサポートしていません。
Gauche は \xNN スタイル (二桁固定、セミコロン終端なし) を使っています。 これは一般にソースコードには表われません。 (Unicode エスケープ \uNNNN が好まれます。) しかし、 write によるデータファイルのダンプに現れ、大惨事になります。 いくつかマイナーなリーダの非互換もあります。 例えば Gauche はデリミタとしてシングルクォートを処理するので、 abc'def はシンボル ABC とリスト (quote def) としてパースされます。 R7RS では、これはリーダのエラーです。
私のプランはいくつかのリーダモードを用意することです。
- Legacy Gauche: 完全に下位互換性
- r7rs-compatible: 両方を受入れ、曖昧なときは R7RS を選ぶ
- r7rs-strict: R7RS に準拠していない構文を拒否
サポートしてないライブラリ関数や構文が少しあり、暇なときに徐々に実装しています。 まだサポートされていないかどうかを確認するには lib/r7rs.scm を参照して下さい。 高レベルマクロも R7RS を遵守するように拡張する必要があります。 インターナル define-syntax のサポートはまだです。
* * *
R7RS import フォームは Gauche の import とは異なる動作をします。 Gauche のそれはオンメモリモジュールオブジェクト上で純粋に動作し、ファイルのロードを必要としません。 R7RS import はむしろ、 require と (Gauche の) import で説明される use に似ています。
ふたつの機能をもつ import フォームのオーバーロードをどうするか、私は時間をかけて選択肢を熟考しました。 R7RS の import のように動作するよう Gauche の import を変更するか? 最終的に、私は完全に分けたフォームを実装することに決めました。 Gauche の import はほとんどが R7RS にない define-module フォームで使われるので、多くの混乱は起こらないと期待しています。 我々はいつでも Gauche の import を import-module のような何かに名前を変更できます。