タグ

architectureとpipesに関するnsyeeのブックマーク (2)

  • I/Oストリーミングライブラリの実装の基礎 - 後編 - Pixel Pedals of Tomakomai

    前回の続きである。予告通り、2つのストリーミングの「出力」と「入力」をつなげる処理、そして、ストリームの命令列を解釈する処理系を実装する。 2つのストリームを1つにする(考え方) 「出力」と「入力」をどうくっつけるといいのか。それぞれのストリームは命令の列なので、2つの命令の列があると考えられる。ちょっと考えると、これらをうまく並べ替えることで、1つの命令の列を作れることがわかる。 例えば、「Notify(1), Wait(2), Done(3)」という列の出力を、「Wait(4), Notify(5), Done(6)」という2つの列の入力につなぐことを考えよう。様々な処理をつなげる場合、取り出したい演算結果は下流で生成されると考えられるだろう。そこで、合成後の命令の列は下流のWait(4)から開始される。Wait(4)では上流からのデータを期待するので、次は上流の命令であるNotify

    I/Oストリーミングライブラリの実装の基礎 - 後編 - Pixel Pedals of Tomakomai
  • I/Oストリーミングライブラリの実装の基礎 - 前編 - Pixel Pedals of Tomakomai

    conduitやpipesなどのストリーミングライブラリの実装は結構わかりにくい。Pipes to Conduitsという一連のエントリが分かりやすい解説なのだが、それでも序盤からFunctorやFreeモナドを駆使していてハードルが高めな印象を受ける。 理解するには自分で実装するのが一番の近道だろうから、このエントリでごく簡単なストリーミングライブラリを実装してみよう。ストリーミングライブラリではI/Oを扱うのが目的であるため、来であればモナドを扱えるように実装しなければ意味がないのだが、ストリーミングの基的な仕組みとしてはモナドは重要ではないので、ここでは純粋な値のみを扱うストリームを作成する。 ストリームを表す型 ここが一番重要かつわかりにくい部分だと思われる。今回の実装では、「入力」「出力」「結果」の3つの型をストリームで利用する。が、「出力」と「結果」の違いとはいったいなんな

    I/Oストリーミングライブラリの実装の基礎 - 前編 - Pixel Pedals of Tomakomai
  • 1