Gauche:R7RS-large
R7RS-largeのサポート状況。適宜更新。
Red Edition
https://github.com/johnwcowan/r7rs-work/blob/master/RedEdition.md
| ライブラリ名 | 元srfi | サポート |
scheme.list
| srfi-1 | ✓ (0.9.6) |
scheme.vector
| srfi-133 | ✓ (0.9.6) |
scheme.sort
| srfi-132 | ✓ (0.9.6) |
scheme.set
| srfi-113 | ✓ (0.9.6) |
scheme.charset
| srfi-14 | ✓ (0.9.6) |
scheme.hash-table
| srfi-125 | ✓ (0.9.6) |
scheme.ilist
| srfi-116 | ✓ (0.9.10) |
scheme.rlist
| srfi-101 | ✓ (0.9.10) |
scheme.ideque
| srfi-134 | ✓ (0.9.6) |
scheme.text
| srfi-135 | ✓ (0.9.10) |
scheme.generator
| srfi-121 | ✓ (0.9.6) |
scheme.lseq
| srfi-127 | ✓ (0.9.6) |
scheme.stream
| srfi-41 | ✓ (0.9.9) |
scheme.box
| srfi-111 | ✓ (0.9.6) |
scheme.list-queue
| srfi-117 | ✓ (0.9.6) |
scheme.ephemeron
| srfi-124 | ✓ (0.9.9) *partial |
scheme.comparator
| srfi-128 | ✓ (0.9.6) |
- Ephemeronのサポートは完全ではない。datumからkeyへの強参照がある場合、 他にkeyが強参照されてなくても回収されない。規格上はそれでも問題ないが。
Tangerine Edition
https://github.com/johnwcowan/r7rs-work/blob/master/TangerineEdition.md
| ライブラリ名 | 元srfi | サポート |
scheme.mapping
| srfi-146 | ✓ (0.9.8) |
scheme.mapping.hash
| srfi-146.hash | ✓ (0.9.8) |
scheme.regex
| srfi-115 | ✓ (0.9.9) |
scheme.generator
| srfi-158 | ✓ (0.9.8) |
scheme.division
| srfi-141 | ✓ (0.9.8) |
scheme.bitwise
| srfi-151 | ✓ (0.9.8) |
scheme.fixnum
| srfi-143 | ✓ (0.9.8) |
scheme.flonum
| srfi-144 | ✓ (0.9.8) |
scheme.bytevector
| R6RS bytevectors | ✓ (0.9.10) |
scheme.vector.@
| srfi-160 | ✓ (0.9.9) |
scheme.show
| srfi-159 | ✓ (0.9.10) |
Warts
あちゃー見落としてたなーということがらのメモ。
scheme.vector : vector-fold
kons手続きに渡される引数の順序がfold, string-foldと逆
gosh> (fold cons '() '(1 2 3)) (3 2 1) gosh> (string-fold cons '() "123") (#\3 #\2 #\1) gosh> (vector-fold cons '() '#(1 2 3)) (((() . 1) . 2) . 3)
先行したsrfi-43のvector-fold (konsの第1引数にインデックスが渡され、第2引数がseed) から単にインデックスを除いた結果と思われるが…
R6RSのfold-leftと同じ順だし、一貫性にはvector-fold-leftが良かったな
てかMLに投げてた https://srfi-email.schemers.org/srfi-133/msg/4224107 尻切れとんぼになってる。 srfi-160で同じ問題でひっかかったのでまた投げてみるか。
scheme.bytevector : bytevector-copy, bytevector-copy!
R7RS-smallとシグネチャが異なる。
(bytevector-copy! target tstart source [sstart send]);; scheme.base(bytevector-copy! source sstart target tstart length);; scheme.bytevector
(bytevector-copy vec [start end]);; scheme.base(bytevector-copy vec);; scheme.bytevector
importする時に除外するなりリネームするなりすればいいんだけど、同じR7RSという体系の中で同名でインタフェースが違う手続きがあるのは気持ち悪いな。
scheme.stream : stream-take, stream-drop, stream->list
他の *-take/*-drop 系と異なり、長さの方が先に来る。
scheme.rlist
元srfiは「実装のプリミティブデータ型を置き換える」ことも視野に入れてて Schemeのプリミティブと同名のAPIにしてるけど、プリミティブのpairとは違う、 単なるO(log n)でアクセス可能なリストデータ型として使いたい場合、このAPIは かなり使いにくい感じがする。improper listを認めちゃったせいで(プリミティブの置き換え を目指すなら認めないわけにはいかないのだが)何かと余分なチェックが必要になるし、 データ型として活用するにはAPIが足りない。 今から考えるなら、properなリストのみでO(log n)を実現するデータ構造のライブラリを別に作った方が良かったと思う。