[erlang-questions] Why single-assignment with non-shared state?

[Richard Kelsall]

Tobias Gerdin wrote:
> I do not understand why the single-assignment restriction exists in  
> Erlang (even though I very much enjoy functional programming) given  
> that processes do not share state. What is the problem with mutable  
> state in a concurrent system when other processes cannot access other  
> processes' state?

Erlang is fundamentally about extreme reliability. The features have
been chosen to make it as reliable as possible and it's remarkably
good at this. Part of this is achieved by giving the programmer
a very clear view of how the code works and when it goes wrong
the ability to easily remove the bug. So a 'variable' is local
to a function and is only 'assigned' a value at one place in the
code. This reduces the complexity of the code. If a function were
to overwrite a variable then crash it would be more difficult to
see what went wrong because we would have deleted the original value
and if the variable were assigned values at several places in the
function we might not know which assignment statement gave it the
wrong value. Single assignment effectively gives each value a different
name to clarify the code.

Consider also the difficulties of hot code change - which increases
reliability by decreasing the cost of fixing bugs - if you keep values
in places other than local to functions in single assignment variables.
Would you interrupt a long running for-loop to change the code, but
try to retain the values of the variables? Complicated. The function
call in Erlang is the transition from the old to the new version of
the code. Loops - which is where a traditional language would normally
use destructive assignment - are modeled in Erlang as a sequence of
tail-recursive function calls passing the loop state across in the
parameters. So the programmer is encouraged to write short functions
and carefully consider the state required next time round the 'loop'.
This makes hot code change easier.

I think that's about right. Corrections welcome.


Richard.