I uploaded two packages to hackage that may interest readers of this list.
- https://hackage.haskell.org/package/streaming
- https://hackage.haskell.org/package/streaming-bytestring
It's probably a terrible idea!
`streaming` is an attempt to implement `FreeT` in the style of
`Pipes.Internal`, with a zillion more
associated functions. There is a Prelude especially for the fundamental
'Producer' case - `Stream ((,) a) m r` and
its iterations, `Stream (Stream ((,)a) m) m r` . Functor-general
operations are in `Streaming` and use a pipes-like
nomenclature of using an `s` to express functor-generality, e.g. maps,
splitsAt, folds etc etc.
The `Streaming.Prelude` uses regular prelude names and replicates
`Pipes.Prelude` and `Pipes.Group` as far as is
possible -- but turning the pipes into functions as you would expect.
`streaming-bytestring` is just the obviously correct implementation
`Data.ByteString.Lazy`
(but with the same `Pipes.Internal` maneouver.) It tries to follow the
api of the bytestring library
as far as possible, with some us of typical pipes language. Here
Producer ByteString m r
as it is used in `Pipes.ByteString`, passes over into the monadic
ByteString m r
I'm not sure I've succeeded yet in hiding the implementation in either
case; it is only
in the much more general `streaming` case that there may be some genuine
trouble I am overlooking.
Strangely I had hit on the idea of naming the strict pair `Of a b` before
seeing the similar attempt
of ertes' `fuse`; it is almost inevitable where you re-express
Producer a m r
as
Stream (Of a) m r
but I adopted his contructor, `a :> b`.
I conceived this scheme ages ago, but was bent on using fancy optimization
schemes. When it occurred to
me just to follow Gabriel's method in Pipe.Internal - and that
`Data.ByteString.Lazy` already incorporated
highly optimized versions of the natural Prelude of functions - it was
mostly mechanical. I was amazed by
the speed of the `ByteString m r` operations. (In some places I don't have
the well-thought-out
material from Data.ByteString.Lazy to work with, so there are no doubt some
really bad operations in there!)
Anyway, part of interest is that it de-pipes (and de-lensifies) some of the
material in
Pipes.Prelude, Pipes.Group and Pipes.ByteString so that you can see what
Gabriel is thinking more clearly. Pipes is incapable of expressing the
distinction between
ByteString m r
Stream (Of B.ByteString) m r
and uses the latter to implement the former, which is the basis of much of
the difficulty people
have with the library, for example, the chronic difficulty with the type of
lines, which here appears as
ByteString m r -> Stream (ByteString m) m r
exactly corresponding to the type in Data.ByteString.Lazy
LB.ByteString -> [LB.ByteString]
The pipes user naturally expects the equivalence
Producer ByteString m r ~ Stream (Of B.ByteString) m r
-- since after all that's what it is! -- but Gabriel is systematically
forcing the equivalence
Producer ByteString m r ~ ByteString m r
The pipes-group/pipes-bytestring correspondence
([a],[b]) ~ Stream (Of a) m (Stream (Of a) m r) ~
Producer a m (Producer a m r)
(ByteString, ByteString) ~ ByteString m (ByteString m r) ~
Producer ByteString m (Producer ByteString m r)
[[a]] ~ Stream (Stream (Of a) m) m r ~
FreeT (Producer a m) m r
[ByteString] ~ Stream (ByteString m) m r ~
FreeT (Producer ByteString m) m r
emerges very naturally from the material. (In ertes' library FreeT is
called List, which is perhaps better).
I implemented some of the shell-like examples from the io-streams tutorial
here https://gist.github.com/michaelt/6c6843e6dd8030e95d58
The Streaming.Prelude module could use a tutorial, but the little ghci
examples in the haddocks might be of use.
Again, properly arranged, they might operate as a sort of preliminary
tutorial for pipes-group and pipes-bytestring, I don't know.
yours Michael
--
You received this message because you are subscribed to the Google Groups
"Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
