<br><br><div><span class="gmail_quote">On 29/01/2008, <b class="gmail_sendername">Jonathan Amsterdam</b> <<a href="mailto:jbamsterdam@gmail.com">jbamsterdam@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> The core Erlang developers are well aware of the techniques<br>> needed to support destructive updates in GC:d heaps.<br><br>Apologies if my tone came across as patronizing. I just wanted to<br>explain my position without assuming anything.<br>
<br>> 2. As soon as destructive updates are supported, people<br>>    will use them. From what I've heard from Ericsson folks,<br>>    the lack of destructive updates is actually a positive<br>>    thing for them, presumably due to program reliability and<br>
>    programmer productivity.<br><br>This is something I've wondered about. Are there any<br>production-quality, scalable programs that do not use mnesia, d/ets<br>tables or process dictionaries?  That would be cool, but it seems to<br>
me that when you're dealing with huge amounts of real-world data that<br>can change, the copying involved in purely functional data structures<br>would kill you.</blockquote><div><br>Of these three only process dictionaries come across as being
fundamentally mutable data structures, and then only in a limited way. Mnesia is based on ets.
While ets may seem like a mutable data structure (again in the limited
way like process dictionaries) they can actually be modeled, and
implemented, as processes. You don't actually create messages today and
send them, by copying in the BEAM, but you do the copying bit. Ets
tables also have a lot of the process semantics as well. If  table ids
were pids then you would be there. Think of being able to do operations
directly on tables on other nodes. :-)<br></div>
<br>
As to whether the copying kills you there is only one way to find out and that is to measure.<br><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 3. The combination of message passing and mutable data breaks<br>>    the semantics of Erlang, or that of mutable data, and limits<br>
>    the choices the Erlang implementors can make. Suppose P1<br>>    sends a term T to P2. P2 inspects it. Later, P1 updates<br>>    some part of T. Should P2 observe that change?<br>>    - if yes, the semantics of Erlang is now fundamentally altered,<br>
>    - if no, the semantics of mutable data is severely restricted.<br>>    Furthermore, each choice creates new hard constraints on how<br>>    the runtime system may implement process heaps and message<br>>    passing.<br>
><br><br>This is the most compelling reason, for me.</blockquote><div><br>I think there would be great semantic problems in adding  mutable data structures to a system which does not have them. If you allow the the mutating to reach between processes then you have added a "feature" which distinguishes between local and remote processes. There are very few such "features" today which I think is a VERY Good Thing. They cause problems in that programs which work suddenly don't work because someone moved a process to another node without knowing that somewhere deep inside there happened to be some sharing. We might as well add locks, mutexes and synchronisation primitives.<br>
<br>I am still unclear as to what problem you are actually trying to solve.<br><br>Robert<br><br></div></div>