[erlang-questions] Process Dictionary limitations??

[Eric Newhuis]

Heheh when may we expect the Emacs refactoring macro for this?  LOL

On Oct 10, 2012, at 11: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.
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions