Our vision is that send/expect should work according to the default distributed-process semantics, but one ought to be allowed to vary the semantics of channel-based communication (as opposed to actor-based) according to what is relevant to the application. E.g. an application ought to be able to give up reliability for better latency/throughput on a channel-by-channel basis.

That pretty exciting. I will have to put aside some time to tryout Cloud Haskell on top of your ZeroMQ layer. I would love to see a simple example of how this would work with different reliability settings in a ping-pong example. On Mon, Mar 31, 2014 at 1:34 PM, Edsko de Vries wrote:

Hi Mathieu,

That sounds great! It's great to see that the redesign of Cloud Haskell with a pluggable Network.Transport layer is in fact being used. Good stuff!

Edsko

-- You received this message because you are subscribed to the Google Groups "parallel-haskell" group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

-- Patrick Wheeler Patrick.John.Wheeler@gmail.com Patrick.J.Wheeler@rice.edu Patrick.Wheeler@colorado.edu