Hi Vance -  Thanks for the explanations for the different approaches in Erlang - this is great.  Hopefully this follow-up doesn't make me sound like a troll - but I can't help but notice that ets and even Mnesia is recommended before process dictionary (which is very heavily frowned upon) in this thread, and I am not sure if I understand the reason, unless process dictionary is technically inferior or broken.  From FP perspective, neither is pure, so why one better than another?

<br><br>There must be a reason for the level of discouragement about a built-in facility. <br><br>If this is a trite question - I apologize in advance. <br><br>Thanks,<br>yc<br><br><div><span class="gmail_quote">On 10/17/07, 

<b class="gmail_sendername">Vance Shipley</b> <<a href="mailto:vances@motivity.ca" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

vances@motivity.ca</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;">YC,<br><br>As I see it the process dictionary has one and only one

legitimate purpose and that is to store process data for OTP tools such as the debugger.  If you are building a library to add tool functions to arbritray code modules than using the process dictionary may be reasonable.

If you need a variable to persist through function calls you would normally pass it as a function argument.  If there are too many consider storing variable data in records and pass the record (i.e. #state{a=1, b=2, ...}).

<br><br>If there is too much process data for that approach look<br>to using ets.  Beyond that look to mnesia.<br><br>For a purely functional solution use a seperate process to<br>store the data and use message passing.<br>

<br>        -Vance<br></blockquote></div><br>