<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10pt"><div class="" style=""><span style="font-family: monospace; font-size: 10pt;" class="">"X is a process id for a process that expects</span></div><span style="font-family: monospace;" class="">messages of type Y".</span><div><font face="monospace"><br></font></div><div><font face="monospace">Difficult issue, in my opinion. </font></div><div><font face="monospace"><br></font></div><div><font face="monospace">I know of a couple of related ways to do this. First, the concurrent versions of ML, among others, often have "typed channels" for process communication. Personally, I find them awkward to use but they do provide a way to type a form of message passing. <br></font><div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family:
HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 10pt;" class=""> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;" class=""> <div dir="ltr" class="" style=""> <font size="2" face="Arial" class="" style=""> On Friday, August 29, 2014 12:11 AM, Richard A. O'Keefe <ok@cs.otago.ac.nz> wrote:<br class="" style=""> </font> </div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;" class=""> <br class="" style=""><br class="" style=""> <div class="" style=""><br class="" style="">On 29/08/2014, at 2:18 AM, Xiao Jia wrote:<br class="" style="">> <br class="" style="">> So what if we have both Erlang(-style) concurrency and C++ performance (for number crunching, ...) in some new language (yet to be developed)?<br class="" style=""><br class="" style="">C++ performance relies on
several things.<br class="" style="">One of them is the type system.<br class="" style="">We know how to get close-to-C performance in a functional<br class="" style="">language; Xavier Leroy did an impressive job with OCaml.<br class="" style="">It depends on a good type system.<br class="" style=""><br class="" style="">The trick is to extend the type system to send and receive.<br class="" style="">This seems like the weakest aspect of Dialyzer: I cannot<br class="" style="">say "X is a process id for a process that expects<br class="" style="">messages of type Y".<br class="" style=""><br class="" style="">Get the type system right and the rest will follow.<br class="" style=""><br class="" style="">Of course, one of Erlang's strengths has always been that you<br class="" style="">don't *have* to use types.<br class="" style=""><br class="" style="">Having said that, I must emphasise once more that<br class="" style="">"I am writing in C++" does NOT
imply "my code is efficient".<br class="" style="">I have known *interpreted* Scheme to run faster than<br class="" style="">*compiled* C++. Memory management is a tricky subject and<br class="" style="">manual (delete) or semi-manual (smart pointers) is NOT always<br class="" style="">faster.<br class="" style=""><br class="" style="">> Regardless of community size, reusable libraries and other "human-related" issues commonly faced by any new language, can we say such a new language is better than both Erlang and C++ because it (potentially) beats both in performance and concurrency, respectively?<br class="" style=""><br class="" style="">One of the saddest errors in classical philosophy was the use<br class="" style="">of "better" as though it was unequivocal. Let E be Erlang,<br class="" style="">C be C++, and N be the new language. It is possible that<br class="" style=""> N >= E (concurrency)<br class=""
style=""> N > E (performance)<br class="" style=""> N < E (readability)<br class="" style=""> N < E (human error rate)<br class="" style=""> N > C (concurrency)<br class="" style=""> N >= C (performance)<br class="" style=""> N < C (readability -- unlikely but for the sake of argument)<br class="" style=""> N < C (human error rate -- again unlikely but still)<br class="" style="">We would then have to say that N is better than E and C<br class="" style="">AND ALSO that N is worse than E and C.<br class="" style=""><br class="" style=""><br class="" style=""><br class="" style="">_______________________________________________<br class="" style="">erlang-questions mailing list<br class="" style=""><a ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org" class="" style="">erlang-questions@erlang.org</a><br class=""
style=""><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank" class="" style="">http://erlang.org/mailman/listinfo/erlang-questions</a><br class="" style=""><br class="" style=""><br class="" style=""></div> </blockquote> </div> </div> </div><div><span style="font-family: monospace;" class=""><br></span></div><div><span style="font-family: monospace;" class="">Second, Sven-Olof Nyström's old Erlang type analyzer was, at least in theory, capable of inferring types for erlang messages and processes. However, even if we remove a number of language features, an Erlang process can contain many receives connected by arbitrary control flow. Thus, I'd expect that a gen_fsm or suchlike where you essentially implement protocols could potentially yield a very complex type. (Granted, that statement depends on what sort of precision you're looking for in your types. The more I think of the nature of an "erlang process type", the less
clear it gets.) </span></div><div><span style="font-family: monospace;" class=""><br></span></div><div><span style="font-family: monospace;" class="">The model checking guys, McErlang etc, might also have some way of dealing with this, but I haven't investigated that.</span></div><div><span style="font-family: monospace;" class=""><br></span></div><div><span style="font-family: monospace;" class="">Best,</span></div><div><span style="font-family: monospace;" class="">Thomas</span></div></div></div></body></html>