[erlang-questions] Process Dictionary limitations??

[Richard O'Keefe]

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.