A simpler interface for pipelined peers that don't have interesting `Receiver` results

[nfrisby]

Is your feature request related to a problem? Please describe.

It occurred to me that the pipelined mini protocols I'm working on don't have an interesting c type. IE the Receivers do have useful side-effects but do not have any result value that would be interesting for the mini protocol Peer to react to.

In fact, this seems plausibly to be the common case. The only reason I have so far imagined the Receiver result being interesting is if the Peer wanted to control the scheduling of any expensive computations instead of promptly doing them whenever the message arrives.

Describe the solution you'd like

Disclaimer: I haven't thought this through; I'm merely spelling out my intuition.

I propose:

• Add a Pipelined_ constructor to IsPipelined.
• Add a YieldPipelined_ :: ... -> Receiver ps pr st' st'' m () -> Peer ps pr Pipelined_ st'' m a -> Peer ps pr Pipelined_ st m a constructor to Peer.
• Provide a driver that doesn't retain the result of each Receiver.

Describe alternatives you've considered

My "workaround" is to use today's Pipelined and settle for calling collect whenever possible merely to discard the ()s that the driver is uselessly retaining each time my Receiver runs.

Are you willing to implement it?

• Are you? 😃

Maybe we could pair program it during a weekly meeting we're in together!

[nfrisby]

You could add the N back argument to Pipelined_, but that would require adding a very impotent-looking Collect_.

Why shouldn't the peer be allowed to use Await and Yield when there are cs they haven't acknowledged? That's never been clear to me.

[coot]

Without the type level N, the API will be easier to use, it will not show up in wrappers (e.g. the *.{Client,Server} modules we have for all mini-protocols in ouroboros-newtork, which is a good thing.

Another benefit is a simpler driver which won't need to have an internal queue with all the collected cs.