<div dir="ltr"><div>My €.2, as a computer scientist (categories for the win) and an Erlang coder:</div><div><br></div><div>There are certainly formal differences between Erlang-style concurrency and the many different Actor Models that have appeared in the literature (cf. Aπ-calculus). The runtime doesn't use a reduced set of communication primitives as a foundational concept, such as in the pi-calculus formulations of Actor Models. I haven't seen any proof of the fairness/progress property for Erlang, either.</div>
<div><br></div>On the other hand, it is more or less trivial to _implement_ models of Actors in Erlang, whichever of the many proposed semantics for actors you choose. <div><br></div><div>Although I have never completed the exercise, I believe quite strongly that you could also fully embed Erlang's style of concurrency in both abstract actor models and operational (process calculi) implementations of those, with relatively simple, or even trivial, translations; eg selective receive as a set of actors with a receptionist.</div>
<div><br></div><div>I'd go so far as to say that Erlang and the Actor Model are in the same programming paradigm, but with different axioms in their semantics-- although that's of course conjecture without (large, tedious) proof....</div>
<div><br></div><div>In my opinion, strictly separating Erlang-style concurrency and the Actor model is only of academic interest; unless you are implementing, say, an Erlang runtime of course. The differences are certainly relevant to category theorists, language theorists, mathematicians working in the Curry-Howard domain and so forth, but for the general programmer the differences are more or less implementation details ("up-to the usual nonsense").</div>
<div><br></div><div>By contrast, although it is just as relevant, we generally don't discern between object-oriented models that allow either contra- or covariant inheritance (or both). Should we really distinguish process-oriented models by the semantics of the "becomes" relation?</div>
<div><br></div><div>/// Raphael</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 4:40 AM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Monday 23 June 2014 11:22:36 Ngoc Dao wrote:<br>
> > In many ways an Erlang system does have an OS feeling about it. At least<br>
><br>
> I think so.<br>
><br>
> I think so, too:<br>
> <a href="http://www.slideshare.net/ngocdaothanh/cloud-erlang" target="_blank">http://www.slideshare.net/ngocdaothanh/cloud-erlang</a><br>
<br>
</div>I enjoyed the abbreviated cut-down (once I got over the use of the empty,<br>
warped, buzzsound term "cloud"... its necessary to attract attention from a<br>
certain type of party, but they aren't the sort who are really going to<br>
embrace what you have to say).  Its a good reference to explain why Erlang<br>
implies a lot more than just a language. Much better, I think, to do like<br>
you've done here and treat Erlang/OTP as a system that supports a very<br>
different model of computation than most folks are accustomed to than to start<br>
them on the language syntax first.<br>
<br>
Actually, quite a few interesting early attempts at explaining Erlang as a<br>
system up-front have come out over the last few threads. Most of this stuff is<br>
unpolished, but represents a lot of effort in a good direction.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>