[erlang-questions] Why single-assignment with non-shared state?
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
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
- 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