Quantcast

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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

On Feb 26, 2017, at 12:24 PM, Edmund Cape <[hidden email]> wrote:

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

--

--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

On Sunday, February 26, 2017 at 3:50:40 PM UTC-5, Gabriel Gonzalez wrote:
B might sometimes be faster than A because `(~>)` is easier to optimize than `(>->)`

On Feb 26, 2017, at 12:24 PM, Edmund Cape <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="TeyMmmiDAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">edmun...@...> wrote:

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

--

--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

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

On Sun, Feb 26, 2017 at 3:41 PM, Edmund Cape <[hidden email]> wrote:
Does a series of yields still exploit the benefits of decoupling? (e.g., independently able to stop the stream) - E

On Sunday, February 26, 2017 at 3:50:40 PM UTC-5, Gabriel Gonzalez wrote:
B might sometimes be faster than A because `(~>)` is easier to optimize than `(>->)`

On Feb 26, 2017, at 12:24 PM, Edmund Cape <[hidden email]> wrote:

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

--

--

--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Edmund Cape
Perfect.  Thank you!  - E

On Sun, Feb 26, 2017 at 7:45 PM, Gabriel Gonzalez <[hidden email]> wrote:
In `p >-> q`, both `p` and `q` can stop the stream

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

On Sun, Feb 26, 2017 at 3:41 PM, Edmund Cape <[hidden email]> wrote:
Does a series of yields still exploit the benefits of decoupling? (e.g., independently able to stop the stream) - E

On Sunday, February 26, 2017 at 3:50:40 PM UTC-5, Gabriel Gonzalez wrote:
B might sometimes be faster than A because `(~>)` is easier to optimize than `(>->)`

On Feb 26, 2017, at 12:24 PM, Edmund Cape <[hidden email]> wrote:

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

--

--

--
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 [hidden email].



--

Edmund Cape, PhD MBA
(917) 715-8299

--
Loading...