<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 1:12 AM, Robert Virding <span dir="ltr"><<a href="mailto:rvirding@gmail.com" target="_blank">rvirding@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The data in an ets table and a process dictionary is not mutable!</blockquote></div><br>The memory in C is not mutable!</div><div class="gmail_extra"><br></div><div class="gmail_extra">We can construct a C system by having each memory slot be a process supporting two operations</div><div class="gmail_extra"><br></div><div class="gmail_extra">    get : Loc -> Value</div><div class="gmail_extra">    set : Loc -> Value -> unit</div><div class="gmail_extra"><br></div><div class="gmail_extra">Hence, we can implement the C language without ever mutating things. Rather, we send messages to each memory location. I note that the asynchronicity of the "set" operation is truer to reality than the usual assumption: the cache is not immediately updated and requires coordination / memory-barriers to be safely updated. In other words, the modeling would be truer to a real system than the usual implementation where store updates are assumed to happen at once. Heck, the memory is not even linearizable in the usual sense.<br><br clear="all"><div>The other view is that this is a silly idea and of course ETS is a mutable store. But I don't think so! In reality, what is going on here is that mutability is all about process communication. And the communication is effectful, not the storage contents!</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">J.</div>
</div></div>