Design consideration: when are pipe objects enabled with the benefits of decoupling?

[Edmund Cape]

If presented with the following design choices:

A.  getRecords h >-> parsePipe >-> P.print

              ...where the getRecords both awaits and yields

B. ( (a -> m b) ~> (b -> m c) ) h >-> P.print 

   

               ... where each of the kleisli arrows yields

Does A have 2 decoupled points

  #1. between getRecords h >-> and parsePipe

  #2. between parsePipe and P.print's

Versus B only one between the final yield from the second k :: (b -> m c) and the await from P.print?

If so, is there a performance consideration?

Thanks in advance for letting me know.

- E

[Gabriel Gonzalez]

B might sometimes be faster than A because `(~>)` is easier to optimize than `(>->)`

--
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 haskell-pipe...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

[Edmund Cape]

Does a series of yields still exploit the benefits of decoupling? (e.g., independently able to stop the stream) - E

[Gabriel Gonzalez]

In `p >-> q`, both `p` and `q` can stop the stream

In `f ~> g`, only `f` can stop the stream

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipes+unsubscribe@googlegroups.com.

[Edmund Cape]

Perfect.  Thank you!  - E

--
You received this message because you are subscribed to a topic in the Google Groups "Haskell Pipes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/haskell-pipes/_r0O4QwFZjs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to haskell-pipes+unsubscribe@googlegroups.com.

To post to this group, send email to haskel...@googlegroups.com.

--

Edmund Cape, PhD MBA

(917) 715-8299

edmun...@gmail.com