How can Erlang support both single assignment and dynamic typing?

Question

Let me start saying I am only a computer science enthusiast, with relatively little knowledge of the subject. My question is: if single assignment is the idea that a variable (e.g., A) can only be assigned a single value without that value to change (A = 1, A = 2 -> error) how can a language also have dynamic typing? If the value of a variable cannot change, surely it cannot change its type... right?

Answer 1

If a language is dynamically typed that means that it is not generally possible to determine the type of any given expression without running the program. That doesn't have to mean that variables have to be able to change their type, just that it's not possible to tell which type the variable has without running the program.

So take this piece of code as an example:

A =
    if some_condition -> 42;
    true -> "hello"
    end

Here we can not know whether A is a number or a string without knowing whether the condition is true or false (which we can't generally know without running the code as it can be an arbitrarily complex expression). In a statically typed language the above would be illegal, but in Erlang it is allowed.

Answer 2

Single assignment is easy, if A is bound to 1 (or the reverse, I don't know how to use this verb :o) any other assignment will fail and create an exception

1> A = 1.
1
2> A = 1.0.
** exception error: no match of right hand side value 1.0
3> %% even strongly typed!

Dynamic typing is a different concept, it means that the type of variables are checked at run time, not at compile time. for example if we use a function working on list with our A variable like lists:reverse(A) the compiler will not complain, and it will generate a valid beam file which will crash if this weird line of code is executed.

Coming from C, this looked like a regression to me, because it reveals the error very late, when it seems to be very easy to detect. But in fact there are some advantages and obligations to do so, particularly with Erlang:

• Erlang programs are not linked, so you can execute - safely - a module which already include functions that need other modules that are not yet written
• Erlang support code reload, so the verification done at compile time may be obsolete.
• The syntax is lighter, you don't need to define any variable type.
• It complies with the "let it crash" mantra (and more important the supervision tree).

Answer 3

Dynamic typing is not about assignment. Erlang does not perform type cheks in compilation time, but do it in runtime.

Let say, I have some function:

foo() ->
  %% Perform some computation
  Result.

Which type will have function result? I don't now. Erlang too. Next, let say, I have another function:

bar(Arg) ->
  %% Some computation
  Result.

Which types I can pass as argument of this function? Again, this decision will be taken only in runtime.

Answer 4

You are dealing with two very different concepts. Dynamic Typing means that the type safety of a program is determined at run-time, as opposed to static-typing which does the same at compile time.

A useful oversimplification might be that a statically typed language is constructed such that type safety (or correctness) can be determined by the examination of the text of the program written in that language. Dynamically-typed languages do not have the language features/constructs such that this is possible, instead type-safety is discovered at run-time. Like all things computer science, one type-system represents trade-offs of pro's and con's as compared to the other type-system.

Single assignment, on the other hand, says nothing about type. it just means that a variable can only be assigned a value once.

Suppose you have a function F(), if we say

X = F(),
Y = X ++ "I hope F returned a string",
Y = "This cannot work in a single-assignment language".

A statically typed language would be able to infer the type-safety of the string concatenation at compile time, while a dynamically-typed language would (probably) not be able to make this determination until run time.

The fact that Erlang is single assignment implies that Y could not be reassigned some other value after the (hopefully) successful string concatenation.