[erlang-questions] How about a new warning? Was: Re: trouble with erlang or erlang is a ghetto

[Richard O'Keefe]

On 4/08/2011, at 9:55 PM, Tim Watson wrote:
> I suspect most experienced Erlang developers don't get bitten by this.
> Going back to the blog post that was the genesis of the original
> thread, the person in question (whose name I've forgotten) was
> complaining about this because the match fails at runtime. I think
> it's just an example of someone whose not used to single assignment
> and finds that they don't like it in practise. I would qualify that
> statement by pointing out the poster also went on to actually suggest
> that single assignment is bad. I don't agree but each to their own.

The person in question was Tony Arcieri, who built Reia
(see http://reia-lang.org/).  There are three things that seem
obvious about Tony Arcieri:
(1) He likes Ruby.  (Nobody who didn't would want to build
    something like Reia.)
(2) He knows rather a lot about Erlang.  (Nobody who didn't
    *could* build something like Reia.)
(3) He is a skilled programmer.  (Nobody who wasn't could
    get something like Reia working and out there -- as long
    as directories don't include dots in their names...)

It is important to understand the distinction that Tony Arcieri
correctly makes between
(A) single assignment in the *semantics* (data are immutable), and
(B) single assignment in the *syntax* (variables can be assigned
    only once).
The point he makes is that you can have (A), which he seems to be
happy with, without requiring (B), which he is not: you can treat
re*assignment* as re*binding*.  Thus in

	X = f(),
	X = g(X),
	X = h(X)

each occurrence of X on the left would be a new binding, equivalent to

	X0 = f(),
	X1 = f(X0),
	X2 = h(X1)

but without requiring the programmer to keep track of numeric suffixes.
There's a classic paper showing that the imperative programming language
Euclid can actually be viewed as a functional programming language using
such renaming tricks (and taking advantage of the fact that procedure
interfaces had to specify _all_ the variables that could be used (extra
inputs) and set (extra outputs) and the aliasing rules that meant that
in-place mutation could not be detected).  This _does_ include loops.

A language treating assignment as rebinding could look more comfortable
to an ex-imperative programmer without actually sacrificing any of the
virtues of Erlang.  It's not a change that could be made to Erlang by
now, but it certainly would not need a new VM, and it would not introduce
any failure modes that are not now present.

I strongly criticised a recent suggestion of Tony Arcieri's, but while I
personally do not feel a need for conventional-seeming variables in
Erlang code, there is much good sense in his position on single assignment.


I