

Single Assignment Myths (in Erlang) - ash
http://tonyarcieri.org/articles/2008/09/30/single-assignment-myths

======
13ren
I agree there's much confusion about Erlang concurrency being related to it
being a functional programming language, when in fact it's due to pure message
passing. I think this misconception is because some functional programming
features are good for concurrency, and Erlang is functional and is good at
concurrency - so one would expected it to use the features of the former to
achieve the latter.

I write the following to clarify my own concepts, and seek
confirmation/criticism:

Single assignment and debugging: In Armstrong's book, he says an advantage of
single assignment is that you know what value a variable has (that it hasn't
changed). However, each level of recursion has a different set of instances of
the same variables, with different values. I don't think these two cases -
rebinding a variable vs. creating a new instance of a variable with a
different value - are really that different, except that it is easier to track
the path of execution with recursion. In this sense, _iteration_ is somewhat
similar to Dijkstra's _goto._

Single assignment is mathematical: In my high school, an excellent English
teacher questioned a programming statement of mine, that "x = x +1", saying "I
don't know much mathematics, but I know _that's_ wrong". For me, this
highlights the difference between programming vs. mathematics. Functional
programming is more like mathematics in this way, and I feel that people who
love functional programming also love mathematics (in the sense of proving
theorems etc), and also have a solid education in the fundamentals. It seems
to me that "single assignment" in mathematics has deep consequences for
proving things - which I am yet to grasp properly.

BTW: Armstrong is definitely a mathematician-type - who else, when asked to
design a phone control system, _formulates an algebra_ ?

~~~
jbert
"I agree there's much confusion about Erlang concurrency being related to it
being a functional programming language,"

While the term "functional programming language" is sometimes abused to mean
different things, isn't the canonical meaning "functional" == "no mutable
state"?

If I've understood his rebuttal correctly, he's not adding mutable state, he's
allowing a variable to be rebound to different (immutable) values. i.e. his
multiple-assignement language is still functional in the sense above.

The difference is that if you have two bindings to the same value, mutable
state means that both bindings see an update to that value.

This wouldn't happen with "multiple assignement and immutable values" (if you
reassign the binding of one of the two, the other is still bound to the old
value).

~~~
anamax
I consider the values of a program's variables to be part of its state.

It's somewhat odd (read "probably a mistake") if a variable can be visible
before it is bound in a functional language. If the execution model does
anything other than block until a variable's binding is available, its bind
state is mutable state, with all of the problems that entails.

------
newt0311
Good article. This article demonstrates why at some point in a CS course,
people need to write their own compiler. So that the points made in the
article are largely obvious.

