[erlang-questions] Process Dictionary limitations??

[Charles Hixson]

On 10/10/2012 09:31 PM, Richard O'Keefe wrote:
> You can think of the process dictionary this way:
>
> 	If there is a function clause
>
> 		f(X, Y, Z) ->  A = g(X, Y), B = h(Z, A), q(A, B)
>
> 	replace it by
>
> 		f(X, Y, Z, D0) ->
> 		{A, D1} = g(X, Y, D0),
> 		    {B, D2} = h(Z, A, D1),
> 		    q(A, B, D2)
>
> 	and replace
>
> 		    get(K)
>
> 	by
>
> 		    {get(K, D), D}
>
> 	and
> 		    put(K, V)
> 	by
> 		    {V, put(K, V, D)}
>
> I've omitted exception handling, but it's not actually
> all that different.  Tedious rather than difficult.
>
> So there's an important sense in which it doesn't spoil the
> functional purity of the language.  (I got this idea from a
> Xerox blue-and-white CS technical report giving a functional
> semantics for Euclid.)  There are bad things that can happen
> in imperative languages that still can't happen in Erlang.
>
> One big bad thing *can* happen.  If you call a function you
> haven't read, you do not know what it is going to do to the
> process dictionary.  It could change the value associated
> with any key; it could delete any key; it could add any
> key->value mapping.  Even specifications don't help,
> because although there have been several type systems that
> include effects, the type system Erlang now uses is not one
> of them.
>
>
I thought process dictionaries were "per process".  If so, and I don't 
export the values (which I don't intend to), then how would any other 
part even have access to them?

What these would be used for is things like adjusting the weight of a 
weighted graph cell, or deciding that a cell was too inactive, and 
should be rolled out.  (I haven't worked out just how to do that, 
wanting to decide first if I should learn Erlang, or look for another 
language that could do what I need.)  In analogy to C, they would be the 
equivalent of a static local variable.  Or perhaps a C++ class private 
variable is closer.

-- 
Charles Hixson