conduit 0.3 そして 0.4 へ

山本和彦 @kazu_yamamoto

.@tanakh やはり、釈明したじゃないですか！ :-)

Hideyuki Tanaka @tanakh

BufferedSourceもなくなったかー

Hideyuki Tanaka @tanakh

Conduit、バージョンが上がるたびにいろんなところがgreatly simplified されるけど、最初のは何だったんだ…

Hideyuki Tanaka @tanakh

Pipesに欠落していたもの：「リソース管理はpipesと直交する。ResourceTを使えばよろしい」← これは違う。ResourceTは最終的にリソースが解放されることを保証するに過ぎず、なるべく早く解放する手段はない

Hideyuki Tanaka @tanakh

制御フローのサポートが甘い：enumerator使ってた時辛かった点。データストリームにアクセスするIterateeモナドのコードが生きてるようにしないといけない（ちょっと意味分からん）conduitはBufferedSourceの概念でこれを解決してた

山本和彦 @kazu_yamamoto

.@tanakh 単に Header パーサの食べ残し(ボディ)が捨てられちゃうから、アプリがボディを食べられないと言う意味でしょう。

山本和彦 @kazu_yamamoto

"$$&" は、食べ残した src も返す。

Hideyuki Tanaka @tanakh

遅延I/Oはやっぱりサポートしたい

Hideyuki Tanaka @tanakh

Redditでの（conduitサイドの）議論：「Pipesの定義は一見正しそうだけど、実際のコードを見るまで正しく動くか信じられない」「conduitのキモ、BufferedSourceが完全に無視られてる」「エレガントさってのは極めて主観的で、無意味なコンセプト」

Hideyuki Tanaka @tanakh

要するに、pipesは興味深いアイデアだけど、採用するに早すぎる。研究が必要だ。今日バスに６時間乗らなければいけないので、その研究に時間をさこうじゃないか。ってわけで、Pipesを実装してみた。得られた知見は次の通り。

Hideyuki Tanaka @tanakh

・確かに統一された型でconduitを再実装することはできたようだ。そしてリソースセマンティクスも正しく動作しているように見える・Pipeをconnect/fuseする関数も正しく定義できるようだ・一番重要だけど、これで実装はすごいシンプルになった。

山本和彦 @kazu_yamamoto

リソース管理を圏論で証明した？ Haskell コミュニティは恐ろしすぎるな。。。

山本和彦 @kazu_yamamoto

.@tanakh つ http://t.co/rmOlPIs0

Hideyuki Tanaka @tanakh

@kazu_yamamoto これは読みました

Hideyuki Tanaka @tanakh

ところで、BufferedSourceはどうなったのか？違うアプローチ取ることにした。（BufferdSourceの説明は略）。connect&redume演算子、$$&を導入。これはSourceとSinkを接続して、その結果と、最終状態を返す演算子。これでよかったんや！

Hideyuki Tanaka @tanakh

Iterateeとかでは、enumerator $$ iteratee は iterateeになるから、このへんの問題は発生しなかったように思うのだけどどうなのか？これがnon-standard制御フローのサポート？たしかに、途中でsinkの結果を取得できるのは便利だけど

Hideyuki Tanaka @tanakh

かくして、SourceとSinkはなくなり、さらにBufferedSourceもなくなり、これが正しく動作している。これは良かったのか？未だ一つ問題が残っている。これは本当により良い解法なのか？人々は、ただひとつの型を目にする。そしてそれで分かった気になる。

Hideyuki Tanaka @tanakh

で、SinkでVoidを使う必要があることに困惑する。あるいは、SourceとConduitがいまやモナドになったことによって、その結果は出力型ではなくて、（なんかよくわからない）結果の型になった。

Hideyuki Tanaka @tanakh

でまあ、要するに、彼（Snoymanさん）は意見が欲しい。Conduit-0.4は良いとは思うけど、分離された型はそれはそれで違った良さがあった。Source/Sink/Conduitをnewtypeにするのも一つの手だし。これで意味のあるインスタンスだけに絞れるし、エラーメッセ

Hideyuki Tanaka @tanakh

私見を書いておくと、僕はSourceとConduitがモナドになるととても嬉しいです

Hideyuki Tanaka @tanakh

むしろ、unified typeとかどうでもいいから、SourceとConduitをモナドにして欲しかった

山本和彦 @kazu_yamamoto

.@tanakh enumerator でソースを引き回せないことが、Conduit を作った動機です。HTTP proxy が作れなかったのです。(enumerator を入れ子にすればできるらしいけど、WAI がそれさえ禁止していた。)

Hideyuki Tanaka @tanakh

@kazu_yamamoto なるほど。enumeratorではsource $$ sink がsinkになるので出来るんじゃないかと思っていたんですが、waiがそういうことを禁止していましたか。

Hideyuki Tanaka @tanakh

まあとりあえずBufferedSourceはいまいちかっこよくないなあと思ってたので、$$&演算子のほうがいささかクールなのではないでしょうか。

山本和彦 @kazu_yamamoto

.@tanakh ソースを引数として渡せることが、conduit の本質です。$$& も、それを実現する方法。