Pros & cons of Erlang single assignment and type checking

[Ulf Wiger]

On Sun, 25 Nov 2001, Sheheryar Qadir wrote:

>Being new to Erlang i was reading about the language from
>whatever source that i could find however i was unable to find
>essential features of Erlang's non destructive assignment
>statement

- Single assignment and side-effect free functions mean that you
  can be absolutely certain that once a variable has been given
  a value, it will maintain that value. This makes it a lot
  easier to reason about a program.

- Single assignment and pattern matching go hand in hand.
  For example, a pattern like:

  lookup(Key, [{Key, Value}|_]) -> Value.

  makes absolute sense if you know that Key, once given a
  value, will maintain that value. The pattern above will work
  whether you evaluate it from left or right. The first occurence
  of Key will result in Key being bound to the corresponding
  value; the second will succeed iff that value is identical to
  the first one. This type of programming leads to very concise
  programs, and it's hard to achieve with destructive assignment.

>plus where can i find up to date information about the work
>thats been done or is going on to incorporate static type
>checking in Erlang and the consequences of not accomodating
>type checking.

Erlang does have type checking, but it is performed at run-time.
Many of the types expressed in Erlang are implicit, as parts of
the pattern matching.

  {ok, Fd} = file:open(File, [read]),

asserts that the function file:open/2 must return a tuple of size
2, where the first element is the atom 'ok'. The second element
can be anything, and our program doesn't care, as long as the
file module recognizes it as a file descriptor in subsequent
function calls. The ability to handle 'any type' data with great
ease can be a major advantage.

Furthermore, changing code in a running system is much easier to
accomplish using dynamic type checking. Even when types have
changed from one version to the next, we can easily make
functions backward compatible with the old types by keeping the
old patterns.

Many object to dynamic type checking on grounds of efficiency. A
good compiler can certainly use static types to produce much more
efficient code, since much more of the semantics are known at
compile time. I haven't worried too much about this aspect, since
I've found (a) that Erlang is fast enough for my purposes, and
(b) in the kind of (complex) programs we develop, type checking
is hardly ever the reason for poor performance -- it's rather bad
choice of algorithms or programs doing lots of stuff they
shouldn't be doing.

This is not to say that static type checking can't be superior at
times. There is a type checker for Erlang that's being developed,
and the general idea is that it could be used in areas where
static type checking would really add benefit. One obvious such
area is an interface module.

However, tacking on a static type checker after the fact is
difficult, especially if the goal is to keep the basic flavour of
the language.

Dynamic type checking has its strengths and weaknesses. I don't
view Erlang's dynamic types as a defect of the language -- quite
the opposite, but I recognize that others are much in favour of
static type checking -- and tend to go with languages like
Haskell or ML.

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks