ストリーミング
Lazyな文字列による入出力はリソース管理がガバガバで危険なだけでなく、例えば入力、出力、その他の処理が入り混じったような処理が表現できない。そこで、値を入力・出力しつつアクションを実行できるような構造が数多く発明された。
無党派
conduitに代わり、現在 wai などで主流となっている方式。
入力ストリームを IO a 、出力ストリームを (a -> IO ()) -> IO () -> IO () として表現する。入力は単にIOアクションを繰り返し実行するだけで、出力する関数は \write flush -> write "hello" >> flush のように与えられた関数を繰り返し呼び出す。
> こんでゅいっと？こんじっと？ → kάnd(j)uːɪt(US) kˈɔndjuɪt (UK)
data ConduitT i o m r という、入力、出力、
モナド、結果をパラメータとする変換器を中心に据える。
FP Completeの他のパッケージと連携しやすく実用性も高い。
双方向性があるという点では多機能だが、処理しきれなかった残りを出せないという致命的な弱点がある。それが気にならないなら親しみやすく実績もあるパッケージだ。
カスタマイズ可能な入力と、モノラルな出力を持つMachineTに加え、Mealy、Mooreなどの小物系がやたら充実している。
Stackで値を戻したり、多入力に対応したりと、柔軟性は高いが採用実績はかぐわしくない。
> Beautiful Streaming, Concurrent and Reactive Composition
非常に速いことを謳っているが、
環境がストリーミングライブラリを使わない方向に遷移してしまったため、そこまでシェアを獲得できなかった不遇なライブラリ。幾度となく仕様変更を重ねており、現在は並行処理・
IOに特化したよくわからないものになっている。
FreeT と同等の構造を生産者として利用し、消費者は単にそれを受け取る関数とするライブラリ。リスト感覚で扱えるAPIは魅力だが、ストリームを分配できるcopyという関数も存在するが、極めて遅くあまり実用的ではない。
双方向性や残余の処理など入れられるものは全部突っ込んだ色物
国産パッケージで、しかもそれなりに速い。
Tap r s m rを受け取りsを返す、m上で動く生産者。
Joint r m s パラメータを入れ替えたおかげでApplicativeになった。
ListT r m s こちらはリスト変換子として働く。現環境においては最速。
Sink t m a 生産者t ( Tap r s など)を消費する計算のモナド。無駄に一般化されているのが特徴的で、drinkery最大の特色である。
Awaiter s m a sを受け取り、最後にaを返すクラシックな消費者。
Distiller tap r s m tapを消費し、rを受け取ってsを返す変換機。その実体は Tap r s (Sink tap m)
豪華ではあるが、ほぼ
ListTのためだけに使われるパッケージと成り果てた。
IO上でしか動かせないという重大な制約の代わり、卑怯なほどの速度を手に入れた(しかしvectorには及ばなかった)。
snapにおける採用実績がある。
ストリーミング黎明期に作られた消費者ベースのライブラリ。生産者は、消費者を受け取って消費者を返す関数として表現されている。パフォーマンスは劣悪(要素あたりの処理時間が他の10倍以上)、APIもかなり低水準なため、今あえてiterateeを選ぶ理由は存在しない。
関連記事