<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 18, 2017, at 7:19 AM, Michel Fortin &lt;<a href="mailto:michel.fortin@michelf.ca" class="">michel.fortin@michelf.ca</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Great writeup. Here's a few comments about the manifesto, actors and value semantics specifically.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""># About actors and data isolation</div><div class=""><br class=""></div><div class="">Can I call global functions like sin(x) in an actor? Surely you need to be able to do that. But how can the compiler know which functions are safe to use and which are out of bound for an actor?</div></div></div></blockquote><div><br class=""></div><div>The design I outline allows you to call it, and punts on the problem of safety:</div><div><a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#global-mutable-state" class="">https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#global-mutable-state</a></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Actors shouldn't access&nbsp;the global mutable state and thus should only call functions that do not access the global mutable state. We probably need a concept of a functions being pure (as in not accessing the global mutable state) for that.</div></div></div></blockquote><div><br class=""></div><div>I’m not aware of a practical model to achieve that, but if there were, more safety would provide more goodness :-)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""># About the part "Does a type provide proper value semantics?"</div><div class=""><br class=""></div><div class="">I would argue that this is the wrong question. Most types are a hybrid form of value and reference semantics. All you need is to limit what you do to what is proper value semantics and forbid the parts that use reference semantics. Otherwise you are pessimising the capabilities of the types.</div><div class=""><br class=""></div><div class="">For instance, has Array&lt;UIView&gt; value semantics? </div></div></div></blockquote><div><br class=""></div><div>By the commonly accepted definition, Array&lt;UIView&gt; does not provide value semantics.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">You might be tempted to say that it does not because it contains class references, but in reality that depends on what you do with those UIViews.</div></div></div></blockquote><div><br class=""></div><div>An aspect of the type (“does it have value semantics or not”) should not depend on the clients. &nbsp;By your definition, every type has value semantics if none of the mutating operations are called :-)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> If you treat the class references as opaque pointers (never dereferencing them), you preserve value semantics. You can count the elements, shuffle them, all without dereferencing the UIViews it contains. Value semantics only end when you dereference the class references. And even then, there are some exceptions.</div></div></div></blockquote><div><br class=""></div><div>I agree with you that the model could permit all values to be sent in actor messages, but doing so would give up the principle advantages of mutable state separation. &nbsp;You’d have to do synchronization, you’d have the same bugs that have always existed, etc.</div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>