I'm really happy about this! I've been wanting a package like this for
some time, for two main reasons:
* It greatly simplifies the inferred types and error messages of the
`pipes-group`/`pipes-bytestring`/`pipes-text` packages
* It's more efficient (because it uses the same trick as `Pipes.Internal`)
On 8/26/15 9:15 AM, Michael Thompson wrote:
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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
--
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].
