mth
Purely functional, elegant, correct, incremental and composable stream processing that is CPU and memory efficient. This is our (worthy) goal, but where do we start? This problem space is being extensively explored across a variety of languages and libraries, each with subtly different trade-offs and not-so subtly different APIs and terminology. However, these libraries share common goals, and mos
How to build library-agnostic streaming sources
The Haskell ecosystem has numerous libraries for effectful stream programming, including, but not limited to: List conduit enumerator io-streams iterIO iteratee list-t logict machines pipes Unfortunately, this poses a problem for library writers. Which streaming library should they pick when providing effectful streaming components? Sometimes the correct answer is: none of the above! We can often
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
conduitやpipesなどのストリーミングライブラリの実装は結構わかりにくい。Pipes to Conduitsという一連のエントリが分かりやすい解説なのだが、それでも序盤からFunctorやFreeモナドを駆使していてハードルが高めな印象を受ける。 理解するには自分で実装するのが一番の近道だろうから、このエントリでごく簡単なストリーミングライブラリを実装してみよう。ストリーミングライブラリではI/Oを扱うのが目的であるため、本来であればモナドを扱えるように実装しなければ意味がないのだが、ストリーミングの基本的な仕組みとしてはモナドは重要ではないので、ここでは純粋な値のみを扱うストリームを作成する。 ストリームを表す型 ここが一番重要かつわかりにくい部分だと思われる。今回の実装では、「入力」「出力」「結果」の3つの型をストリームで利用する。が、「出力」と「結果」の違いとはいったいなんな
Episode 6 - Gabriel Gonzalez and Michael Snoyman on Pipes and Conduit - The Haskell Cast
Episode 6 - Gabriel Gonzalez and Michael Snoyman on Pipes and Conduit Recorded: 2014-02-23, Published: 2014-03-03 Gabriel Gonzalez and Michael Snoyman join us to discuss their solutions to the problems with lazy IO. Gabriel's pipes library focuses on equational reasoning while Michael's conduit library promises deterministic resource handling. Gabriel and Michael have already debated the merits an
Model-view-controller, Haskell-style
I'm releasing the mvc library for model-view-controller (MVC) programming in Haskell. I initially designed this library with games and user interfaces in mind, but the larger goal of this library is to provide a mathematically inspired framework for general-purpose component sharing in Haskell. This library differs in a significant way from other MVC libraries: this API statically enforces in the
How to model handles with pipes
I receive repeated questions for how to implement a Handle-like API similar to io-streams using pipes even after I outlined how to do this about a year ago. However, I don't blame these people because that tutorial uses an out-of-date (and uglier) pipes-3.2 API and also takes an approach that I felt was a bit inconsistent and missed the mark, so this is a rewrite of the original post, both to upgr
Streaming logging
I see many beginners use WriterT [a] in their programs to log outputs like this: import Control.Monad.Trans.Class (lift) import Control.Monad.Trans.Writer import Prelude hiding (log) log :: Monad m => String -> WriterT [String] m () log string = tell [string] example :: WriterT [String] IO () example = do log "Printing 1 ..." lift $ print 1 log "Printing 2 ..." lift $ print 2 main = do strings <-
Shortcut fusion for pipes
Rewrite rules are a powerful tool that you can use to optimize Haskell code without breaking backwards compatibility. This post will illustrate how I use rewrite rules to implement a form of shortcut fusion for my pipes stream programming library. I compare pipes performance before and after adding shortcut fusion and I also compare the peformance of pipes-4.0.2 vs. conduit-1.0.10 and io-streams-1
pipes-4.0: Simpler types and API
I'm announcing pipes-4.0 which greatly simplifies the types and API of the pipes ecosystem. For people new to pipes, pipes is a compositional streaming library that decouples streaming programs into simpler, reusable components. The purpose behind pipes is to simplify effectful stream programming for both library authors and application writers. Library authors can package streaming components int
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
process + pipes = process-streaming
Reddit - Dive into anything
pipes-p2p
pipes-concurrency
pipes-4.0.0: Compositional pipelines