[Haskell-cafe] ANNOUNCE: pipes-core 0.0.1

[Mario Blažević]

On 12-03-11 01:36 PM, Chris Smith wrote:
> On Sun, Mar 11, 2012 at 11:22 AM, Mario Blažević<blamario at acanac.net>  wrote:
>>     No, idP does terminate once it consumes its input. Your idP>>  p first
>> reproduces the complete input, and then runs p with empty input.
> This is just not true.  idP consumes input forever, and (idP>>  p) =
> idP, for all pipes p.
>
> If it is composed with another pipe that terminates, then yes, the
> *composite* pipe can terminate, so for example ((q>+>  idP)>>  p) may
> actually do something with p.  But to get that effect, you need to
> compose before the monadic bind... so for example (q>+>  (idP>>  p)) =
> (q>+>  idP) = q.  Yes, q can be exhausted, but when it is, idP will
> await input, which will immediately terminate the (idP>>  p) pipe,
> producing the result from q, and ignoring p entirely.

     Sorry. I was describing the way it's done in SCC, and I assumed 
that pipes and pipes-core behaved the same. But GHCi says you're right:

 > :{
| runPipe ((fromList [1, 2, 3] >> return [])
| >+> (idP >> fromList [4, 5] >> return [])
| >+> consume)
| :}
[1,2,3]


     May I enquire what was the reason for the non-termination of idP? 
Why was it not defined as 'forP yield' instead? The following command 
runs the way I expected.

 > :{
| runPipe ((fromList [1, 2, 3] >> return [])
| >+> (forP yield >> fromList [4, 5] >> return [])
| >+> consume)
| :}
[1,2,3,4,5]