Shiro Kawai
shiro****@lava*****
2004年 2月 22日 (日) 14:02:42 JST
From: Kimura Fuyuki <fuyuk****@nigre*****> Subject: [Gauche-devel-jp] soft-port Date: Sat, 21 Feb 2004 11:39:20 +0900 > At Fri, 23 Jan 2004 19:25:11 -1000 (HST), > Shiro Kawai <shiro****@lava*****> wrote: > > > > いやそもそもの問題は、base64-decodeがストリーム処理をできない > > ためであることにに気づきました。 > > (iport -> oportはできるけど、pipe-portみたいなもので > > つなげてゆく方法がない) > > 長期的にはそっちを改善した方がよさそうです。 > > 実はこれ、message-digestをやったときに気づいていたんですが、そのときは > よくわかってなかったので、Scheme的になにかうまい解決があるのかと思って > 流してしまいました。なかったですね、やっぱり。 パイプのように動作するportというアイディアは、srfi-48 (Intermediate Format Strings) の議論でもちょっと出ていました。 また、この方向でのportの汎用化は、Oleg Kiselyovらともちょっと話しています。 いずれにせよ、soft-portもしくはvirtual portの上に作る、というのは 正しい方向だと思います。 > ひっかかっているのはたぶんこんなところではないかと思います。 > > - Scm_MakeVirtualPortとScm_MakeBufferedPortのどっちでいくか。 > - どっちも入れるとしたら、APIをどうするか。 > - 効率の良い綺麗な実装は可能か。 その通りです。一応、どっちも入れたい方向。重視するのは 効率とわかりやすいAPI。 > - 「バッファになりえるもの」の抽象化をどうするか。 今、uvectorを書き直しています。arrayのback endにも使えるように する方向。バッファ関係もそのへんで入れられないかと。 (mmap APIも付けたいんですが、メモリイメージを単にuvectorとして 見せるべきか特殊なメモリオブジェクトを使うべきか、また、uvector-ailas 等によるメモリ領域の共有を許した場合にGCとmunmapをどう絡めるか、 あたりが見えていません)。 もしよければ、SchemeレベルのAPIから「こんなのがあったらいい」 みたいなアイディア出しとかしてみて下さい。OO的にやるなら<port>を 継承可にしてport-getcみたいなメソッドをオーバロードさせるのが 綺麗なんだろうけど、効率はおもいっきり落ちそうだ… --shiro
