R6RSとR7RSライブラリの比較 - とりあえずリストを作る
とりあえず、R6RSとR7RSのライブラリをシンボルで比較してみて、何が共通で何が独自なのかのリストを作成する。
- https://gist.github.com/okuoku/7f5b3fa0d4dbd0230b9a
- 集計に使ったスクリプト
- https://gist.github.com/okuoku/020f3dbbf7d00c91d21c/2bd47aca28e37714acd0212f5085c3dba63031bf
- 集計結果
元データが手打(!)なので何か間違いが有るかもしれない。
集計結果は、R6RS/R7RSに共通でシンボルが存在するもの、R6RSだけのもの、R7RSだけのものの順に並んでいる。ソートはR6RS規格書順を優先。
例えば、R6RSにだけ存在するSRFI-1サブセットが一目瞭然。というかcons*ってR7RSに無い。。
(rnrs lists) find ---
(rnrs lists) for-all ---
(rnrs lists) exists ---
(rnrs lists) filter ---
(rnrs lists) partition ---
(rnrs lists) fold-left ---
(rnrs lists) fold-right ---
(rnrs lists) remp ---
(rnrs lists) remove ---
(rnrs lists) remv ---
(rnrs lists) remq ---
(rnrs lists) memp ---
(rnrs lists) assp ---
(rnrs lists) cons* ---全部で764エントリも有るが、syntax-caseとかrecord等R6RSに固有なものは無視しても良いので一旦それらは削除する。
- https://gist.github.com/okuoku/020f3dbbf7d00c91d21c/3430b7dd95a29db0ed4a37d329fa908588e80ae5
- R6RS固有のライブラリを削除したもの
- https://gist.github.com/okuoku/020f3dbbf7d00c91d21c/97684832cec9a9099c748897070af29d2174d70f
- さらにcondition関連のシンボルも削除した
- https://gist.github.com/okuoku/020f3dbbf7d00c91d21c/a8708c68dbd017a4426f02e50a3132f2ccfa039e
- (rnrs bytevectors)から多倍長モノを削除
- https://gist.github.com/okuoku/020f3dbbf7d00c91d21c/9b30ff143da7a8320cdd8323fe32e98e624e1fbe
- (rnrs io ports)からcustomポートとtranscoderを削除
string→bytevectorはtranscoderを使うから(rnrs io ports)に入っている。
これで399シンボルまで減った。次に、R6RSとR7RSで機能的に等価なものを1つ1つ見ていって消していく。メジャーなものとしては、R6RSはmap等に複数のリストを渡す場合はリストは等長でなければならないが、R7RSはSRFI-1風に、最も短いリストの分だけ動作することになっている。yuniもSRFI-1動作を取るので、このような差は一旦忘れ、同じものと見做す。
他にも、R7RSの機能がR6RSの同名シンボルのスーパーセットになっているものはいくつか有る。
(rnrs base) case (scheme base)
(rnrs base) syntax-rules (scheme base) しかし、問題なのは互換性のないもの、つまり、R6RSで使われていたものを、R7RSの同名シンボルに置き換えると壊れるケースと言える。ざっと見た限りでは、
(rnrs bytevectors) bytevector-copy! (scheme base) (rnrs records syntactic) define-record-type (scheme base)
くらいしか該当するものが無いような気が。。共通するライブラリを上から見ていくことで、このような語彙を調べておきたい。
