upcoming pipes-core 0.2

39 vues
Accéder directement au premier message non lu

Paolo Capriotti

non lue,
24 juin 2012, 07:18:2124/06/2012
à streamin...@googlegroups.com
Hi all,

I've just finished porting existing pipes-based code to my new Pipe
implementation, which incorporates most of the ideas that we have been
discussing in this mailing list.

You can find the code at the `devel` branches of my pipes repositories:

https://github.com/pcapriotti/pipes-core/tree/devel
https://github.com/pcapriotti/pipes-extra/tree/devel
https://github.com/pcapriotti/pipes-zlib/tree/devel

The new pipes are structured as follows:

- The Pipe type has the extra 'u' type parameter as in Chris's implementation.

- I reordered the type variables and put `m` first. That means that `Pipe` can
no longer be an instance of `MonadTrans`, so I replaced `lift` with an
`exec` function.

I don't mind this change, since `Pipe` is not really a monad transformer in
the classical sense, and it didn't strictly satisfy the laws, anyway
(although it did observationally).

- I added a `MonadStream` class, similar to Chris's, but with an important
difference: input, output, and upstream return types are not associated
types, but type parameters.

For example, here's the type of `yield`:

yield :: MonadStream m => m a b u ()

- Leftovers and auto-terminating awaits are not built-in, but implemented on
top of normal pipes, using `StateT` and `EitherT` respectively.

You can use the `withUnawait` and `withDefer` functions to convert them to
`MonadStream` values.

- Composition has a generalized type:

(>+>) :: MonadStream m
=> m a b u r
-> Pipe (BaseMonad m) b c r s
-> m a c u s

It works with any `MonadStream`, although the second argument is constrained
to be a normal pipe.

This is more or less the code that I plan to release as 0.2.0. Any feedback
would be greatly appreciated.

BR,
Paolo
Répondre à tous
Répondre à l'auteur
Transférer
0 nouveau message