Gauche:R7RS-large

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)

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とシグネチャが異なる。

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)を実現するデータ構造のライブラリを別に作った方が良かったと思う。

More ...