Doing arithmetic is all right, but you won’t get far without being able to store the results somewhere. For that, you use variables. If you read the Introduction to this book, you know that variables can’t be variable in func-tional programming.
In Erlang, variables begin with an uppercase letter by definition. The basic behavior of variables can be demonstrated with these six expressions:
1> One.
* 1: variable 'One' is unbound 2> One = 1.
1
3> Un = Uno = One = 1.
1
4> Two = One + One.
2
5> Two = 2.
2
6> Two = Two + 1.
** exception error: no match of right hand side value 3
The first thing these commands tell us is that you can assign a value to a variable exactly once. Then you can “pretend” to assign a value to a vari-able if it’s the same value the varivari-able already has. If the value is different, Erlang will complain. It’s a correct observation, but the explanation is a bit more complex and depends on the = operator. The = operator (not the variables) has the role of comparing values and complaining if they’re dif-ferent. If they’re the same, Erlang returns the value:
7> 47 = 45 + 2.
47
8> 47 = 45 + 3.
** exception error: no match of right hand side value 48
When you use the = operator with variables on both sides of it, with the variable on the left side being unbound (without any value associated with it), Erlang will automatically bind the value on the right to the variable on the left. Both variables will then have the same value. The comparison will consequently succeed, and the variable on the left side will keep the value in memory.
Here’s another example:
9> two = 2.
** exception error: no match of right hand side value 2
The command fails because the word two begins with a lowercase letter.
n o t e Technically, variables can also start with an underscore (_), but by convention, their use is restricted to values you do not care about.
This behavior of the = operator is the basis of something called pattern matching, which many functional programming languages have, although Erlang’s way of doing things is usually regarded as more flexible and com-plete than the alternatives. You’ll learn more about Erlang pattern match-ing when we visit other data types in this chapter, and also see how it works with functions in the following chapters.
Note that if you’re testing in the shell and save the wrong value to a variable, it is possible to “erase” that variable by using the function
f(Variable).. If you wish to clear all variable names, use f().. These functions are designed to help you when you’re testing, and they only work in the shell. When you’re writing real programs, you won’t be able to destroy values this way. This restriction makes sense if you think about Erlang being usable in industrial scenarios. It’s wholly possible that a shell will be active for years without interruption, and you can bet that a given variable will be used more than once in that time period.
Atoms
There is a reason why variables names can’t begin with a lowercase character:
atoms. Atoms are literals, which means that they’re just constants whose only value is their own name. In other words, what you see is what you get—don’t expect more. The atom cat means “cat,” and that’s it. You can’t play with it.
You can’t change it. You can’t smash it to pieces. It’s cat. Deal with it.
While using single words starting with a lowercase letter is one way to write an atom, there are also other ways:
1> atom.
atom
2> atoms_rule.
atoms_rule
3> atoms_rule@erlang.
atoms_rule@erlang
4> 'Atoms can be cheated!'.
'Atoms can be cheated!' 5> atom = 'atom'.
atom
An atom should be enclosed in single quotes (') if it does not begin with a lowercase letter or if it contains any characters other than alphanumeric characters, an underscore (_), or an at sign (@). Line 5 also shows that an atom with single quotes is exactly the same as a similar atom without them.
I compared atoms to constants that have their name as their values. You may have worked with code that used constants before. For exam-ple, let’s say you have values for eye colors: 1 for blue, 2 for brown, 3 for green, and 4 for other.
You need to match the name of the constant to some underlying value. Atoms let you forget about the underlying values. Your eye colors can simply be blue, brown, green, or other. These
colors can be used anywhere in any piece of code. The underlying values will never clash, and it is impossible for such a constant to be undefined!
(We’ll see how to create constants with values associated with them in Chapter 2.)
Therefore, an atom is mainly useful to express or qualify data coupled with it, usually in a tuple (described in “Tuples” on page 16). Atoms are sometimes (but not often) useful when used alone. This is why we won’t spend more time toying with them here. You’ll see them coupled with other types of data in later examples.
Don’t Drink too muCh kool-aiD
Atoms are really nice and a great way to send messages or represent constants . However, there are pitfalls to using atoms for too many things . An atom is referred to in an atom table, which consumes memory (4 bytes per atom in a 32-bit system and 8 bytes per atom in a 64-bit system) . The atom table is not garbage collected, so atoms will accumulate until the system tips over, either from memory usage or because 1,048,577 atoms were declared .
This means atoms should not be generated dynamically . If your system needs to be reliable, and user input lets someone crash it at will by telling it to create atoms, you’re in serious trouble .
Atoms should be seen as tools for the developer because, honestly, that’s what they are . To reiterate: You should feel perfectly safe using atoms in your everyday code as long as you type them in yourself . It’s only dynamic generation of atoms that is risky .
n o t e Some atoms are reserved words and cannot be used except for what the language designers wanted them to be: function names, operators, expressions, and so on.
These reserved words are as follows: after, and, andalso, band, begin, bnot, bor, bsl,
bsr, bxor, case, catch, cond, div, end, fun, if, let, not, of, or, orelse, query, receive,
rem, try, when, and xor.