In the "Programming Erlang" book it's said that the language uses "single assignment" variables. In other articles about functional programming languages I always read of "immutable values" instead.
Does the wording "single assignment" mean something different from "immutable values"?
In erlang, a variable can be either bound or unbound. You can only assign a value to an unbound variable. And that's where the single assignment comes from, because once the variable is bound, you can no longer assign a new value to it. So in erlang, you can't do the following, even if 0
and 1
are immutable values.
X = 1.
X = 2. // This is not a valid operation
The term immutable is relative to the value of the variable, and not the variable itself. So in some languages, you can assign to the same variable different values that are immutable:
X = immutableValue;
X = anotherImutableValue; // This is a valid operation
Edit: From wikipedia
Immutable Object:
In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.
Single Assignment:
Single assignment is an example of name binding and differs from assignment as described in this article in that it can only be done once, usually when the variable is created; no subsequent re-assignment is allowed. [...] Once created by single assignment, named values are not variables but immutable objects.
The difference is related to the difference between (re-)binding a variable and mutating a value.
"Single assignment" means, that you cannot re-bind a variable with different values, e.g.:
1> A = 1.
2> A = 2.
** exception error: no match of right hand side value 2
"Immutable values" on the other hand mean that you cannot change the values themselves (for example, from a parallel thread), so if you want to want to modify a list, you have to make a copy or something semantically equivalent instead of changing in-place.
Haskell programmer reporting in. Yes, "single assignment" and "immutable values" are both the exact same thing. Haskell takes this concept a bit deeper: everything's value is defined at compile time. Yes, everything.
You might then ask how that is possible, since Haskell can clearly do I/O. The answer is that you when you define an operation that extracts an input from the outside world, you are not defining the value, but merely the operation that extracts it. You never explicitly define the value that is bound. In Haskell, when you do things like:
echo = forever $ do
x <- getLine
putStrLn x
You are not "defining" x
but rather just just telling getLine and putStrLn how to interact. The only thing you are actually defining is echo
, which is nothing more than an action waiting to be run. Clearly, echo
's behavior is defined at compile time, whereas the value of x
is not.
Maybe you already knew that, but I'm writing this also for the benefit of other people who have a similar question about Haskell vs. Erlang.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With