HIRAUCHI Hideyuki
hira****@verys*****
2004年 2月 26日 (木) 04:46:35 JST
平内です。
リファレンス実装(?)に向けて、フィルタがSchemeでどんな風に書けるか（書
きたいか）考えてみました。
フィルタを素直に考えれば、(current-input-port)から読んで
(current-output-port)に書き出すものなんですよね。
base64.scmのbase64-decodeなんかがまさにそれなんですけど。
そういう物をならべると、全部つなげてくれる仕組みを提供してあげれば良い
んでしょうけど。。。
どうも私は引数・戻り値に拘りたくなるんですよね。
なんかportのread-<type>に違和感を感じてしまう。<type>が何種類あれば、
満足できるのかと不安になってしまう。型のないpull/pushがあればいいのだ
けれど、それをportに求めていいのかなぁと。
型無しを求めるのは、pipe-lineの力を最大限に発揮させたいと思うからです。
読み書きの単位がbyteかcharでないと繋がらないというのは、かなり悲しい。
フィルタがオブジェクトを作っても、portのread/writeでやりとり出来る範囲
は決まっているし。
とはいっても、さくっと提供できるのは素直に考えた版なんですよね。
なんてことを考えつつ、以下、引数・戻り値に拘った版の話。
やっぱり、ハンドラは書きたくないと思いました。
ハンドラが無くても、arityとvaluesで流れを調節できそうですしね。
valuesが次のフィルタのarityから溢れたら、valuesを消費し尽くすまで
次のフィルタを呼ぶようにすれば良さげです。
valuesが次のフィルタのarityを満たせないままEOFになったら、残りをEOFで
埋めてしまって良いでしょう。
pipe-lineが賢く調節すべき部分ですね。
MOREは、一つの出力を得るのに何個の入力が必要か分からない場合、どうし
ても必要になります。MOREもなくすことが出来れば言うこと無しなんですけど。
ガード条件があればいいのでは、という気もするんですが、どのみちpureなproc
だけで何とかなる問題ではないんですよね。
SWITCHは、消費者から生産者へ転じるときにあったら便利かと思ったんですが、
arity/valuesで流れを制御するならこれも必要なさそうです。
あとは、一つのフィルタが複数のフィルタを内包出来た方が良いと気付きまし
た（下の擬似コード参照）。
#それにしても、arityとreceiveはR6RSに入るのだろうか。
#arityがSRFIにもなってないとは驚きです。R4RSぐらいでサポートされてても
#ふしぎじゃないと思うのだけど。
--hira
(filter "base64-decode-filter"
;; base64 char filter
;; byte -> byte
(lambda (c)
;; eof-objectならそのまま流す。
;; base64の文字なら数値にして流す。
;; そうでないならmore
v)
;; base64 decode filter
;; byte[4] -> byte[3]
(lambda (v0 v1 v2 v3)
;; base64エンコードする
;; 値の構成要素にeof-objectが混じっていたら、eof-objectを値とする
;; 多値として3つの値を流す。
(values b1 b2 b3)))