@hackage streaming0.1.0.7

Stream can be used wherever FreeT is used. The compiler's standard range of optimizations work better for operations written in terms of Stream. See the examples in Streaming.Prelude for a sense of how simple the library is to use and think about.

Streaming.Prelude closely follows Pipes.Prelude, but cleverly omits the pipes. It is focused on employment with base functors which generate effectful sequences. These appear elsewhere under titles like

pipes:      Producer a m r, Producer a m (Producer a m r), FreeT (Producer a m) m r
io-streams: InputStream a, Generator a r
conduit:    Source m a, ConduitM () o m r

and the like.

Interoperation with pipes is accomplished with this isomorphism:

Pipes.unfoldr Streaming.next        :: Stream (Of a) m r   -> Producer a m r
Streaming.unfoldr Pipes.next        :: Producer a m r      -> Stream (Of a) m r

(If you don't have pipes-HEAD, inline the definition of unfoldr.)

Interoperation with io-streams is thus:

Streaming.reread IOStreams.read     :: InputStream a       -> Stream (Of a) IO ()
IOStreams.unfoldM Streaming.uncons  :: Stream (Of a) IO () -> IO (InputStream a)

The separate Generator a r type in io-streams is intended to permit construction of an InputStream with more possibilities (such as the yield statement). This purpose can as well be met with Stream (Of a) m r, which may be friendlier to the compiler.

A simple exit to conduit would be, e.g.:

Conduit.unfoldM Streaming.uncons    :: Stream (Of a) m ()  -> Source m a

These conversions should never be more expensive than a single >-> or =$=.