R7RS実装のポイント(改)

R7RSのMLにも投稿したけど、R7RS bridgeを実装していて気付いた点。
http://lists.scheme-reports.org/pipermail/scheme-reports/2011-November/001648.html

char-ready?

R7RSはbaseライブラリにchar-ready?が含まれる。これはIEEE Schemeに有るという理由でbaseライブラリに配置されているが、LinuxWindowsではブロッキングI/Oハンドルに対してこれを信頼できる方法で実装できない(ハンドルに対して非ブロックI/Oするしかない)。
近代的なOSでは絶対によく実装できない機能はなるべくbaseに入れないで欲しいが。。

構文の違い

  • vu8がu8になった
  • [や]が言語予約に戻った
  • vector類がself-quoteになった。

角カッコが予約に戻るのはどうかと思うけど、vector類がself-quoteになるのも比較的謎。
冷静にかんがえると、何でいままでそうでなかったのかと思うけど。。
R6RSでは、

'#(1 2 3)

のようにquoteする必要があった。

バッファportがSRFI-6風になった

従来のバッファportはopen-string-output-portのようにポートと取り出し手続きの2値を返していたが、SRFI-6(特殊なポートを返し、そのポートに対して問い合わせるという形)になった。
これ逆は簡単に実装出来る(SRFI-6でR6RSのバッファportを実装するのは簡単)が、R6RSのバッファportでSRFI-6は通常の方法では実装できない。
R7RS bridgeでは、weak hashtableを使って実装しているが、psyntax-moshのようにweakオブジェクトのサポートが無い環境だとどうしようもない。(nmoshはmosh本体のSRFI-6機能を使って実装しているので、そもそもweakオブジェクトを使っていない)

処理系 : Sagittarius

Sagittariusは、Gauche風(= Common Lisp風)のキーワードをサポートしている。このため、SRFI-42のように : で始まるシンボルを持つライブラリをポータブルに書けない。
R7RSでは|symbol|形式のシンボル表記のサポートが要求されているので、他の処理系がこの形式の表記をサポートするまでの辛抱。(mosh以外は大体サポートしていると思うが。。)

処理系 : Racket

Racketは曖昧なライブラリ - つまり、#!r6rsや#langの無いライブラリを読む方法が無い。拡張子を判別してロードするようにパッチする方法が有れば。。
ライブラリに#!r6rsをつけてしまうと、他のR7RSから読めなくなってしまうという問題がある。