WriterT 積んでみた

[swtw7466]

ユーザへのメッセージを受け取る機構として WriterT 積んでみたよ。 それだけといえばそれだけですが。

この積み順だと、tell してから ErrorT がエラーを投げた場合、 先に発生した tell 分はメッセージとして表示されそう(未確認)ですが、 ErrorT でエラーが発生した場合はそこまでの tell のメッセージも破棄したいのであれば、 ErrorT と WriterT の積み順を変えれば自動的にそうなる…かな？

あと各所では「Writer 使うときは差分リストとか使うようにして、 リストの結合順を制御するとパフォーマンスの心配が減るよ」 みたいなことが書いてありますが、 まぁ今回は大量のメッセージを保持したりはしないので (端から Conduit stream に流し込んで捨ててますし)、 その辺のことは(ひとまず現時点では)考えなくてもきっと大丈夫でしょう。

[masaedw]

これやる意味あるのかわからなくなって、ほぼこれと同じコード書いて捨てた……んだけど、まあこれはこれでいっかっていう気分になってきた。

[masaedw]

何が問題かというと、evalとかやってるところが、どう見てもモナド剥がして云々っていうbindの変形にしか見えないということです。 WriterTが積まれることによってますますそれが顕著になりました。 そうするとほんとうは evaluator の型は Conduit PToken (EnvT m) ByteString になってるのが正しいんでないかと思うわけです。 こうなるとevaluatorはもはや lift $ fromToken t >>= eval catchError handler だけになります。 でもって ByteString が出力ってのも変だろうと思うともはやSinkでいいのでは、ってとこまで考えたけど、もはやSinkでいいのだけど、最後にEnvTを実行する方法がわからなくて寝た。

[masaedw]

日本語が怪しいですね

[masaedw]

そういうわけで一旦保留で。

[swtw7466]

それもそーですねぇ。 前に bind の変形じゃんコレ、って言ったのは私自身ですね。

しかし別所でも剥がして積み直してみたいなコードを自分で書いているので、 なんかこう、スタック中段にあるモナドを一旦解決したいみたいなときにどうすんのかとか、 あるいはそもそもそんなことをしたくなるような積み方が問題なんじゃないかみたいな、 そういうのいまいち良く分かんない感じですね。

[masaedw]

そこのところをビギナーなりに考えた結果が Conduit PToken (EnvT m) ByteString なわけですね。 一旦解決したいっていうことについては、たとえばcatchErrorみたいなコンビネータが既に提供されてるだろうという前提で。