<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 29, 2014 at 6:10 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br></div>
The trick is to extend the type system to send and receive.<br>
This seems like the weakest aspect of Dialyzer: I cannot<br>
say "X is a process id for a process that expects<br>
messages of type Y".<br></blockquote><div><br></div><div>This reminds me of session types.  But I have to read (and dig) more about session types since I have no experience with them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I have known *interpreted* Scheme to run faster than<br>
*compiled* C++. <br></blockquote><div><br></div><div>What is the underlying issue?  I always thought interpreted languages cannot achieve good cache efficiency so they are doomed to be much slower given that the same algorithms and data structures are used.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We would then have to say that N is better than E and C<br>
AND ALSO that N is worse than E and C.<br></blockquote><div><br></div><div>Sure.  I meant "better in aspects of performance and concurrency."</div></div>
</div></div>