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

Thomas Lindgren <>
Sun Oct 21 17:21:23 CEST 2007

--- Tobias Gerdin <> wrote:

> But in Erlang since state is not shared between
> processes you would  
> never get race conditions anyway. Single-assignment
> makes a lot of  
> sense when engaging in shared-memory thread-based
> programming, but  
> since that is not the case in Erlang I was curious
> of the philosophy  
> behind single-assignment in Erlang's case.

If you have pattern matching, you can write something
like this:

member(X, [X|Xs]) -> true;
member(X, [_|Ys]) -> member(X, Ys);
member(X, _) -> false.

Consider the first clause. What should be done when
you encounter X twice?(*)

- disallow it by refusing to compile (do not permit
"non-linear patterns")

- interpret it as comparing the two occurrences for

- first assign X the value of argument 1, then the
value of the head of argument 2 (probably not what you

Some languages (ML, Haskell?) chose option 1. Some
languages (Prolog, Miranda, Erlang) chose option 2. 

As an aside, note that many functional languages
permit "reassigning" a variable by introducing a new
scope. You can "reassign" x by writing something like

 let x = 3 in
  let x = 42+x in

which would return 90. (However, this is not real
assignment, it just uses the property that variable
names can be changed.) Anyway, doing this in Erlang
requires somewhat contorted code, but it's possible
and, indeed, sometimes indispensable.


(*) As an extra complication, there normally is no
restriction on the order of pattern matches. Thus, the
compiler could choose to begin compiling member/2 by
matching argument 2 or argument 1 and get somewhat
different code in the end. The compiler can and will
(and should!) exploit this to optimize pattern

In Erlang, binary patterns break this "order
independent" property and _do_ have some restrictions.
But apart from that, you can think of pattern matches
as done in any arbitrary order.

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the erlang-questions mailing list