<div dir="ltr">Thanks for taking the time to comment Jesper. Your comments are certainly illuminating for someone like myself who doesn't know the various details of Erlang's messaging model as deeply as you do.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 11:54 AM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 2:19 AM, Onorio Catenacci <span dir="ltr"><<a href="mailto:Catenacci@ieee.org" target="_blank">Catenacci@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's a free PDF but you have to register on the site.  Given the audience here I thought it might present some interest to some of you. </blockquote></div><br></span>It is an interesting paper, which touches of many of the possible generalizations that are possible in Erlang's messaging model.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* In Erlang, a receive clause is static and receive patterns are not first class variables. In other words, you cannot *combine* different receive clauses which, as the paper mentions, hurt modularity at this level. On the other hand, it is easier to optimize receive clauses if they are static since they will always be module-local.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* The paper curiously omits Concurrent ML as related work. CML subsumes most of the paper and was written back in 1993. In CML there are two abstractions: one, you can combine "receives" by combining the selectors of those receives. Second, the result of a receive are events, which can *also* be combined. It adds another abstraction layer. But the cost of this abstraction is that it will not work in a distributed setting. It is local-only.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* The paper makes no attempt at handling multi-party communication with cycles. Assume a client C, a proxy P and a worker W:</div><div class="gmail_extra"><br></div><div class="gmail_extra">    C messages P</div><div class="gmail_extra">    P forwards the message to W</div><div class="gmail_extra">    W responds to C</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is obviously faster than factoring every message back through P. And it is a quite common pattern in Erlang systems. These are also protocol patterns which needs to be handled well by protocol typing.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* The paper has no mention of error handling in the situation of a combined reactor. We better have a way to identify what part of the reactor failed, and is it possible to let other parts of the combination continue even if other parts failed?</div><div class="gmail_extra"><br></div><div class="gmail_extra">That said, it is *always* nice to have new ways of thinking about concurrency. And the authors definitely has a point with the need for a way to "combine" actors algebraically. It would remove lots of boiler-plate code since the systems can often be "layered". I think the reason we don't have the need is that *most* processes can be written as gen-servers, and their receive patterns are pretty straightforward. They want to read every kind of message and forward it to the callback module, unless the process is part of a call. But this is fairly easy to handle with static receive clauses. I'm not saying the idea is bad, but if you can demonstrate a problem in Erlang which would be helped a lot by the construction, then you have a far better case. If, OTOH, every construction has a direct nice alternative in Erlang, then you may want to conclude the abstraction wasn't so useful after all.</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature">J.</div>
</div></font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Onorio Catenacci<br> <br><a href="http://onor.io" target="_blank">http://onor.io</a><div><a href="http://www.google.com/+OnorioCatenacci" target="_blank">http://www.google.com/+OnorioCatenacci</a><br><div><br></div></div></div></div>
</div>