Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Which library should I use, pipes or pipes-core? #11

Closed
onagano opened this Issue Mar 29, 2012 · 3 comments

Comments

Projects
None yet
3 participants

onagano commented Mar 29, 2012

Hello,

I love Pipes much more than other similar libraries because it's simple and embracing type polymorphism and lazy evaluation of Haskell.

BTW, there is another library using the same module name, Contorl.Pipe, you and @pcapriotti are working on.
https://github.com/pcapriotti/pipes-core

Are there any guideline which to choose? It seems pipes-core is the successor of pipes and the latter is going to obsolete. Or, are you intended to keep evolving this in different way?

Owner

Gabriel439 commented Mar 29, 2012

So Paolo and I both collaborate a lot and share a lot of ideas, but on
some points we disagree so we keep our own reference implementations
split so that people can compare our ideas. pipes-core is simply his
version of pipes and is not intended (by me, at least) to be the
successor to pipes. I don't endorse pipes-core, but I don't prohibit it
either and I continue to work on improving the main pipes package. As
far as guidelines go, his version is intended to be more pragmatic, but
a little messier and less elegant, whereas mine is the more elegant and
purist approach.

I've been working on my own implementation of finalization and
error-handling for the pipes package, and the finalization part is
nearing completion so I expect to release v1.1 within the next month.
If you are interested in an update on how pipes will approach
finalization, then you can read the blog post I just published today
discussing my work on a more elegant finalization framework:

http://www.haskellforall.com/2012/03/haskell-for-purists-pipe-finalization.html

If you compare the ideas in that post with pipes-core, you will see a
lot of parallels with things that Paolo has done, such as his "protect"
function, which is reminiscent of the "heap" combinator I propose.
Also, his library's finalizer passing within the data type was inspired
by my finalizer yielding trick to propagate finalizers downstream, and
his approach is more or less equivalent to mine except structured
differently because he didn't want to put the finalizer in the yielded
output and he preferred to modify the Pipe type. So we do share a lot
of code and have similar finalization/error-handling semantics, but we
go about implementing them in different ways and over time our
implementations have been slowly converging.

Another important distinction is that his currently has an
exception-handling framework. While I'm currently discussing it with
him and I may borrow several ideas from his, my implementation has no
exception-handling code and you would have to roll your own for now
until I roll out that part of the framework. My library only has a
complete solution to just prompt and automatic finalization, but not
exceptions.

On 03/29/2012 12:10 AM, Osamu Nagano wrote:

Hello,

I love Pipes much more than other similar libraries because it's simple and embracing type polymorphism and lazy evaluation of Haskell.

BTW, there is another library using the same module name, Contorl.Pipe, you and @pcapriotti are working on.
https://github.com/pcapriotti/pipes-core

Are there any guideline which to choose? It seems pipes-core is the successor of pipes and the latter is going to obsolete. Or, are you intended to keep evolving this in different way?


Reply to this email directly or view it on GitHub:
#11

I pretty much agree with everything Gabriel wrote, except one thing:

As far as guidelines go, his version is intended to be more pragmatic, but
a little messier and less elegant, whereas mine is the more elegant and
purist approach.

I wouldn't say my version is intended to be less elegant. I also strive for an elegant design, although I like to take the approach of starting from the features I want, and working my way towards a simpler and clearer solution, while Gabriel employs the opposite strategy. I think both are valid, and they actually tend to converge farily quickly to basically identical solutions.

onagano commented Mar 30, 2012

Pipes is new and still at its early stage so it's good to have chances to explore in different ways. My code is small and personal, even experimental, so Gabriel's one matches well, at least now. Sticking to be small and orthogonal may lead it to be a part of the standard library.

Currently both of yours conflict on the module name. I needed to opt out one of them by 'ghc-pkg unregister' command. Of course this is a responsibility of GHC installation manager. I hope people less confuse about this to adopt pipes way.

@onagano onagano closed this Apr 1, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment