HIRAUCHI Hideyuki
hira****@verys*****
2004年 2月 25日 (水) 03:16:58 JST
平内です。
>virtual portではオクテット/文字/バイト列などの読み書き方法をそれぞれ指
>定できるし、別にこれらを全部用意しなくても、たとえば文字の読み出しさえ
>定義しておけばオクテットの読み出しは勝手にシステム側で提供してくれると
>いうすごいことになっています。(というか、予定)
私の提案だと、これは出来なくなっちゃいますね。
あと、filterの組み方次第ではread-byteがリストを返すようなこともあり得る訳で。
・・・やっぱりその仕様は気持ち悪いよなぁ。pull/pushだけにすべきか。
>buffered portはその名のとおりバッファ的な動作をします。obsoleteになっ
>ているopen-input/output-buffered-portを強化したようなものと思えばいい
>でしょう。細かいことはいらないただ大規模データを読み書きするだけという
>場合には、virtual portよりこっちのほうが効率的なんじゃないかと思います。
私の提案はこっち方面をカバーする物ではなさそうですね。
以下、付け足しです。
** source/sinkとportの違い
・source/sinkは読み書きの方法を一つしか提供していないが、portは色々提供している。
・source/sinkはseek出来ないが、(Gaucheの)portはseek出来る。
portからsource/sinkを作成するには、portとpull/push方法を指定すればよい。
(make-source read-char (open-input-string "hoge"))
(make-sink write-byte (current-error-port))
base64-decode-filterの場合は4つのbyteリストを受け取り、
3つのbyteリストを返すという風に実装したいですよね。
MOREとか制御ハンドラとか気にせずに、pureなSchemeで実装したいと。
そのときは、こんな風にadapterを使ってpipe-lineを定義出来ればいいなと思いました。
(execute-pipe-line
(pipe-line
(file-source "tmp1.attach.gz")
(gunzip-filter)
(list-adapter 4 0) ;3more 0catch ;うーん、良い名前が思いつかない。。。
(base64-decode-filter)
(list-adapter 0 3) ;0more 2catch
(bz2-filter)
(file-sink "tmp1.bz2")))
他にも4引数3多値とか。Schemeでの使いやすさはまだまだ考える余地があると思います。
MOREよりも継続を使いたいとか。
うまくマクロで展開できれば、速度もわりと速くなりそうだし、
filterをCで書くのも簡単そうだし。
マクロも継続もちゃんと理解していないから、そんな夢見られるのかもしれないけど。。。
--hira