Variables That Don't Vary
Table of Contents

In the previous post, we learned how to start Erlang's shell, use Erlang like a calculator, and then quit the shell. Today, we'll learn how to store values in variables.

First off, let's just go ahead and say it: Erlang variables are bit weird: they don't vary. Yes. You read that right. Erlang's variables don't vary. Once you set a variable to a specific value, it remains set forever: such variables are immutable. The reason for this seemingly insane scheme is that making variables immutable greatly simplifies programming across multiple processors.

If variables were mutable, programmers would be forced to implement locking strategies for variables each time a process accesses them. Coordinating such systems is difficult to do. Erlang severs that Gordian Knot by simply doing away with mutable state. So this isn't just a case of the Erlang Design Team running mad. There's a reason for why they designed Erlang to work this way. Programming with immutable variables is a pain at first, but over the long run, it helps a lot more than it hurts.

Ok. Let's fire up the shell and start assigning values to variables. Try to figure out what I'm doing as you read. I'll explain below:

Eshell V5.7.2  (abort with ^G)
1> A = 10.
10
2> A.
10
3> A = 20.
** exception error: no match of right hand side value 20
4> b = 20.
** exception error: no match of right hand side value 20
5> B = 20.
20
6> A + B.
30
7> f(B).
ok
8> B.
* 1: variable 'B' is unbound
9> b().
A = 10
ok
10> f().
ok
11> b().
ok
12> q().
ok
13> clay@Hal $

Explanation time:

In line 1 (man do numbered lines make this easier!) I bind the value 10 to the variable 'A' and then end the line, as always, with a period. Notice that the 'A' is uppercase. This brings us to our first rule of variables:

ALL VARIABLES MUST BEGIN WITH AN UPPERCASE LETTER

In line 2, I ask Erlang to read the variable 'A' and return its value. Erlang happily spits back 10. In line 3, I try to rebind A to 20, different value. Erlang complains that it can't do that. It's already bound to 10 and tells me that it can't match the "right hand side value of 20" to A. If that error message strikes you as sounding a bit off, you're on to something, but I'm going to table that discussion until later. For now, just note that I didn't lie to you: variables in Erlang really are immutable, which brings us to our second rule of variables:

VARIABLES ARE IMMUTABLE AND MAY ONLY BE ASSIGNED TO ONCE

In line 4, I try to bind the value 20 to something called 'b' and Erlang once again pitches a fit. Can you figure out why?

Easy. I just violated the first rule of Variables: 'b' isn't uppercase. Don't forget to uppercase variables. It's easy to do.

In line 5, I try binding 20 to 'B' and it's back to smooth sailing. 'B' is uppercase--and thus complies with the first rule of variables--and hasn't been assigned a valus, thus complying with the second rule of variables.

In line 6, I use the '+' to see if I can add A + B. and everything works just as you'd expect. In line 7, I use f(B).--a built-in shell command--to forget the binding between 'B' and the value 20. After this, 'B' should no longer return 20 if asked and 'A' should be the only variable with a value. In line 8, I ask Erlang for the value of 'B' and Erlang informs me that variable 'B' is unbound, meaning that it has no value.

In line 9, I use the shell's built-in command b(). to inspect all of the bindings that currently exist. Since 'B' was just forgotten, that only leaves 'A' and sure enough, Erlang tells us that 'A' is equal to 10.

In line 10, I tell Erlang to forget all variable bindings by using f(). without specifying a particular variable (arity zero). Notice that in line 7 I specified a specific variable to forget. Here I don't so Erlang blasts everything. Be careful when using f()., or you might accidentally tell Erlang to delete all your variable bindings when you only wanted to delete one. In line 11, I verify that Erlang has forgotten all variables by once again using the b(). built-in to show me what variable bindings exist. Erlang responds with just an ok: Erlang's way of saying "Nothing to see here. Move along."

In line 12, I tell Erlang to quit.

Next Stop: Pattern Matching