Impressions of Mozart-Oz

Luke Gorrie <>
Mon Dec 16 16:21:19 CET 2002

Matthias Lang <> writes:

> Roger Price writes:
>  > On Fri, 13 Dec 2002, Vance Shipley wrote:
>  > 
>  > > Q:  Where are the global variables?
>  > > A:  There are none....  Don't use the process dictionary.
>  >                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  > What's wrong with the process dictionary? Is it a matter of performance,
>  > or programming style, or something else?
> Programming style.
> If the answer was:
>   For beginners: Be patient. Complete the course and spend 
>     a few days writing programs without global variables 
>     until you're completely comfortable doing that. You don't
>     need global variables, honest.

Allow me to give my 2 cents from some Dark Side experiments :-)

In Distel we have mutable process-global variables (global scope,
separate value in each process), and I find them very handy. We use
them for all the things that would go into a process-specific #state
record in Erlang. They're especially nice for debugging, since the
buffer/process correspondence means you can just switch into a
process's buffer and use `describe-variable' to poke around its
internal state. It's also more convenient than passing a state record
around everywhere and returning updated copies, since you can just
refer to everything as a regular global variable (and we have

On the other hand, it's probably true that passing the whole state
record around and updating it in the furthest corners of your process
is a sign of poor design. I dare say the win for referential
transparency is when you restrict large parts of the system to only
seeing/updating small parts of the overall state. If every function
signature is "f(State0, ...) -> {State1, ...}" then we're in the same
boat as having globals, but with more typing (as in keyboard). An
interesting question then is whether well-written processes tend to
have a lot of functions like that anyway? I certainly see a lot of
them in daily life, but maybe that's just my own code :-)

On a less-dark-side note, one Distel feature that I'd like to see in
Erlang is a piece of process info giving a one-sentence description,
which the process sets for itself and others can read. That way as
well as e.g. "current function: {yaws_server,loop,3}" in process lists
and crash reports, you could see e.g. "Yaws worker serving HTTP/1.1
request #3 for". Maybe just a proc_lib hack?

Also, on another random note - (nearly) everywhere I use the process
dictionary, I really want dynamic scope, like "call this function with
these dictionary entries, then throw them away." I don't know if this
is true for other people too.

Overall, I'm pretty interested in more formal process state and states
(in the state machine sense) in processes, in the name of runtime
debugging information. I don't know if it would actually be a Good
Thing and have no bright plans, though :-)


More information about the erlang-questions mailing list