pipes-core alternatives and similar packages
Based on the "pipes" category.
Alternatively, view pipes-core alternatives based on common mentions on social networks and blogs.
-
pipes-fluid
Applicative instances that allows reactively combining 'Pipes.Producer's so that a value is yielded when either Producer yields a value. This can be used to create a FRP-like reactive signal-network. -
pipes-category
Allows instances for Category, Arrow and ArrowChoice for 'Pipes.Pipe' using newtypewrapper 'Shaft' -
pipes-break
Utilities for the pipes ecosystem to break and operate on ByteString and Text via delimiters.
CodeRabbit: AI Code Reviews for Developers
Do you think we are missing an alternative of pipes-core or a related project?
README
This library offers an abstraction similar in scope to iteratees/enumerators/enumeratees, but with different characteristics and naming conventions.
Difference with traditional iteratees:
Simpler semantics: There is only one data type (
Pipe
), two primitives (await
andyield
), and only one way to composePipe
s (>+>
). In fact, (>+>
) is just convenient syntax for the composition operator inCategory
. Most pipes can be implemented just using theMonad
instance and composition.Different naming conventions: Enumeratees are called
Pipe
s, Enumerators areProducer
s, and Iteratees areConsumer
s.Producer
s andConsumer
s are just type synonyms forPipe
s with either the input or output end closed.Pipes form a Category: that means that composition is associative, and that there is an identity
Pipe
."Vertical" concatenation works on every
Pipe
: (>>
), concatenatesPipe
s. Since everything is aPipe
, you can use it to concatenateProducer
s,Consumer
s, and even intermediatePipe
stages. Vertical concatenation can be combined with composition to create elaborate combinators, without the need of executing pipes in "passes" or resuming partially executed pipes.
This library is based on the pipes package by Gabriel Gonzalez.