public class Point
    {
        private double x;
        private double y;
        
        // constructors, getters, setters, etc.
    }

    1> P = {point, 10, 20}.
    {point, 10, 20}
    2> P.
    {point, 10, 20}

    3> element(1, P).
    point
    4> element(2, P).
    10
    5> element(3, P).
    20

---

Pattern matching

The = operator in Erlang is actually not an assignment operator, as in Java. It's actually something else: a pattern matching operator. Its job is to take the value of the expression on the right, then match it to the pattern on the left, where the pattern on the left generally contains variables. Its job is to answer this question: Does the value on the right look like the pattern on the left and, if so, is there some set of values I can give to the variables on the left to make the two sides have the same value? If so, the variables on the left are given their new values.

When we use = as we do in Java, the pattern match is trivial: to make the thing on the left have the same value as the thing on the right, give the thing on the left the value of the thing on the right. That's what makes this example work:

    1> X = 3.
    3
    2> X.
    3

But we can express more complicated patterns on the left. For example, we can write a tuple on the left, which can be used to unpackage a tuple's elements all at once.

    1> P = {point, 10, 20}.
    {point, 10, 20}
    2> {point, X, Y} = P.
    {point, 10, 20}
    3> X.
    10
    4> Y.
    20

Here, the interpreter is saying "Is there some set of values I can give to X and Y that make the thing on the left look like the value of P?" P's value is the tuple {point, 10, 20}. The interpreter correctly deduces the right set of values: if X were 10 and Y were 20, both sides of the = operator would be the value {point, 10, 20}. So, the matching succeeds, and X and Y take their new values.

(The algorithm used to do this matching is called unification. If you've ever worked with Prolog before, you'll recognize this algorithm as one that is used in Prolog to match variables with values as rules are searched and applied. It's not especially useful to know the details of how unification works; most of the time, your intuition will lead you to the right expectations.)

As we discussed earlier in the tutorial, variables in Erlang cannot take on a new value once they've been given a value. This rule affects pattern matching in the sense that it requires variables that already have values to retain those values; pattern matching will succeed only if the values of bound variables — those that already have values — do not need to change in order for matching to succeed. Consider the following example:

    1> A = {person, "Alex", "Thornton"}.
    {person, "Alex", "Thornton"}
    2> {person, FirstName, LastName} = A.
    {person, "Alex", "Thornton"}
    3> FirstName.
    "Alex"
    4> LastName.
    "Thornton"
    5> {person, FirstName, LastName2} = A.
    {person, "Alex", "Thornton"}
    6> LastName2.
    "Thornton"
    7> {person, LastName, LastName2} = A.
    ** exception error: no match of right hand side value {person,"Alex","Thornton"}

(Side note: Notice that Erlang supports strings, much like those in many other programming languages. More about them later.)

The pattern match in expression 2 succeeded, because neither FirstName nor LastName already had a value, so they could be given the values "Alex" and "Thornton," respectively. The pattern match in expression 5 succeeded, even though FirstName already had a value, since it had the same value as the second element of A: "Alex." The pattern match in expression 7, on the other hand, failed, since LastName already had the value "Thornton," which did not match the value in the second element of A.

Sometimes you want to match only some values but others you don't care about. In this case, you can use anonymous variables, which have names that begin with an underscore (or are just an underscore by themselves). For example:

    1> Person = {person, "Alex", "Thornton"}.
    {person, "Alex", "Thornton"}
    2> {person, FirstName, _} = Person.
    {person, "Alex", "Thornton"}
    3> FirstName.
    "Alex"

Anonymous variables are never bound to a value. Using an anonymous variable in a pattern matching expression is a way of saying "I don't care what the value of this part of the pattern is." In the example above, only the second element is actually pulled out of the tuple; the third element is irrelevant.

Pattern matching is supported in some other languages — Haskell is an example you may have seen before — and is a feature that generally leads to shorter, clearer code than you can write without it. Erlang supports pattern matching in several places, as we'll see, in addition to just expressions that use the = operator; it works the same way in every place that it occurs.

---

Lists

Lists are sequences of elements. They are implemented in Erlang in the same way as they are in other functional languages like Scheme and Haskell: fundamentally, lists are implemented as a head (the first element) and a tail (the list containing everything except the first element).

Syntactically, lists appear like their counterparts in Haskell, with elements separated by commas and surrounded by brackets. For example, [1, 2, 3] and [a, b, c, d, e, f, g, h, i, j] are lists. Unlike in Haskell (but as in Scheme), Erlang permits lists to have any combination of kinds of elements, so [1, a, 2, b, 3, c] is also a valid list.

One way to break a list into pieces is to use the built-in functions hd and tl, which return the head and the tail of a list, respectively. Examples:

    1> X = [1, 2, 3, 4, 5].
    [1, 2, 3, 4, 5]
    2> hd(X).
    1
    3> tl(X).
    [2, 3, 4, 5]
    4> tl(tl(X)).
    [3, 4, 5]
    5> hd(tl(tl(X))).
    3

Pattern matching provides us with a better approach, however, so hd and tl are rarely used in practice. The syntax [H | T] (which you might recognize from Prolog) is used to describe a list whose head is H and whose tail is T. (This is analogous to the syntax (x:xs) that appears in Haskell.) Depending on where you put it, this syntax can be used to create a new list or to split up an existing list. Examples:

    1> L = [1, 2, 3, 4].
    [1, 2, 3, 4]
    2> [H | T] = L.
    [1, 2, 3, 4]
    3> H.
    1
    4> T.
    [2, 3, 4]
    5> [H1, H2, H3 | TT] = L.
    [1, 2, 3, 4]
    6> H1.
    1
    7> H2.
    2
    8> H3.
    3
    9> TT.
    [4]
    10> L2 = [H2 | TT].
    [2, 4]
    11> L2.
    [2, 4]

In expression 2, we used pattern matching to split the list L into a head and a tail, storing the head in H and the tail in T; the reason that expression 2 splits the list is because the [H | T] syntax appears on the left hand side of the = operator, which means that Erlang will find a value for H and T that make [H | T] look like the list L. Expression 5 is a variant of this syntax, in which we store the first three elements of the list H1, H2, and H3, then the remaining elements in TT. Expression 10 builds a new list, since it appears on the right side of the = operator.

There are other ways to manipulate lists. For example, there is a concatenation operator, ++, which can be used to concatenate two lists together.

    1> [1, 2, 3] ++ [4, 5, 6].
    [1, 2, 3, 4, 5, 6]

It should be noted that list concatenation is more expensive than building a list using the [H | T] notation, so it should be avoided if possible.

---

Strings

Erlang supports strings. Strings are actually not a special, separate data type; they're implemented as a list of integers, where each integer is a character code for some character. For example, the string "Alex" is equivalent to the list [65, 108, 101, 120], since the character code for 'A' is 65, the character code for 'l' is 108, and so on.

This leads us to an interesting question: if strings are lists of integers, how does the interpreter know whether to print a string value like "Alex" or a list of integers like [65, 108, 101, 120]. If you're accustomed to Java, the answer will surprise you: Erlang decides based on the contents of the list. If the list contains only character codes for printable characters, the list is printed as a string; otherwise, it's printed as a list. Examples:

    1> [1, 2, 3, 4].
    [1, 2, 3, 4]
    2> [65, 108, 101, 120].
    "Alex"
    3> "Alex".
    "Alex"

It's not necessary to know what character code corresponds to a particular character; if you need it, you can ask for it using the syntax $x, which evaluates to the character code for the character x. Examples:

    1> $A.
    65
    2> [$A, $b, $c].
    "Abc"

Since strings are implemented as lists, all of the things we can do with lists can be done with strings, as well, including built-in list-processing functions like map, filter, and so on.

---

Modules and functions

A language implementation with only a REPL and interactive commands is only of limited use; at some point, we'd like to be able to write code, save it into a file, then load it up when we need it. Erlang allows us to do this by writing modules.

Modules are collections of functions. Functions serve the same purpose that they do in Scheme or Haskell; they describe how to calculate a result given a sequence of arguments.

An example module follows:

    -module(mymath).
    -export([fib/1]).
    
    fib(0) -> 0;
    fib(1) -> 1;
    fib(N) -> fib(N - 1) + fib(N - 2).

This code should be written in a file named mymath.erl (i.e., the name of the file should match the name of the module, with the extension .erl added).

In order to use this module, we first need to compile it. There are two ways to compile it:

• From an operating system command prompt or terminal window, type the command erlc mymath.erl.
• From the Erlang interpreter, type the command c(mymath)..

Either way, a compiled version of the file, named mymath.beam, will be generated. Erlang is similar to Java, in the sense that the compiler translates Erlang source code to a virtual machine language, which is then executed by the interpreter. .erl files are analogous to .java files, while .beam files are analogous to .class files.

Once compiled, it is possible to call any of the module's exported functions — those that appear in the export list denoted by the -export directive — from the interpreter prompt (or from other modules). Modules are permitted to export as many functions as they'd like; in this case, we've just exported one of them. The name of a function is the name of the module combined with the name of the function, separated by a colon. So, for example, the name of the function exported by this module is mymath:fib. Example:

    1> c(mymath).
    {ok, mymath}
    2> mymath:fib(10).
    55
    3> mymath:fib(20).
    6765

Note that the call to the c function is only necessary if the module has not already been compiled.

There are a few other things worth noting here:

• The fib function takes one argument, but nowhere is the type of that argument defined. Remember that Erlang is dynamically typed, which means that the compiler does no type checking; type checking is done when the function is called, based on what the function does.
• When necessary, the name of the function includes its arity (i.e., the number of arguments it accepts). For example, in the -export directive, the function is listed as fib/1, which means "a function called fib that takes one argument." This is important, because it's possible to overload a function with different numbers of arguments. Note that since you cannot specify the types of arguments, you cannot overload a function on the basis of its argument types; you can overload only on the number of arguments it accepts.
• The fib function is made up of three function clauses. Each clause consists of a head (a signature) and a body (how to calculate a result). The clauses are separated by semicolons and the last one is terminated with a period.
• Pattern matching is used to choose which clause should execute in any given situation, which is often used as a replacement for some kind of "if" or "case" expression. The actual parameters are pattern-matched against the clauses in the order specified; the first match is the one that is executed. So, if fib is passed 0, it returns 0; if it is passed 1, it returns 1; if it is passed some other value N, it returns the sum of calling fib on N-1 and N-2. Order is important here; had we placed the last clause first, there would be no base case and the recursion will continue unabated (until the run-time stack overflows), since any value would match N.

---

Funs

Funs are anonymous functions. Funs are data, as is typical of functions in functional languages like Scheme and Haskell. (Note that, unlike Scheme and Haskell, functions are not data.) This means that funs can be passed as arguments, returned as results, stored in tuples and lists, and so on.

Syntactically, a fun is written in this form: fun(arguments) -> body end; it is an expression whose result is the fun itself. Here is an example of creating and calling a fun:

    1> Square = fun(N) -> N * N end.
    #Fun
    2> Square(3).
    9

More interestingly, though, funs can be used with higher-order functions, as they can in other functional languages like Scheme and Haskell. A predefined module called lists contains a variety of higher-order functions that may be familiar to you, like map, filter, foldl, and zip. These functions accept funs as their "function" arguments. Examples:

    1> Square = fun(N) -> N * N end.
    #Fun
    2> lists:map(Square, [1, 2, 3, 4]).
    [1, 4, 9, 16]
    3> IsPositive = fun(N) -> N > 0 end.
    #Fun
    4> lists:filter(IsPositive, [1, -1, 2, -2, 3, -3]).
    [1, 2, 3]

Note that you can't pass a function as an argument; only funs can be passed this way. However, there is a shorthand mechanism for wrapping a function as a fun:

    1> lists:map(fun mymath:fib/1, [1, 2, 3, 4, 5, 6]).
    [1, 1, 2, 3, 5, 8]

---

Equals vs. identical

There are two ways in Erlang to compare values for equality.

• The =:= and =/= operators mean "identical" and "not identical," respectively. They can be used to compare any two values to see if they are identical to one another (e.g., two numbers that are the same type and have the same value, two lists that have the same sequence of values).
• The == and /= operators mean "equal" and "not equal," respectively. They behave just like the =:= and =/= operators, except where numbers are concerned. For numbers, == and /= enable comparisons between integer and floating-point values. (This means that there is a performance benefit in using =:= and =/=, as no type checking and type coercion is done.)

Some examples of these follow:

    1> [1, 2, 3] =:= [2, 3, 4].
    false
    2> [1, 2, 3] =:= [1, 2, 3].
    true
    3> 3 =:= 3.
    true
    4> 3.0 =:= 3.
    false
    5> 3.0 == 3.
    true

(Side note: Notice that Erlang has boolean constants true and false.)

---

Recursion and the importance of tail recursion

Being a functional language, Erlang does not offer loops, for the simple reason that it doesn't offer the mutable variables that are necessary to support them. This doesn't mean that repetition is impossible; it just means that recursion is the only practical way to do it. (If you've written code in Scheme or Haskell before, this will come as no surprise.)

The potential downside of recursion is the need for the run-time stack to grow the deeper you want to recurse, as an activation record is stored on the stack for each recursive call. This can be a serious problem for functions that are intended to process very long lists; it can be an insurmountable problem for the kinds of functions we'll write later, which are effectively like infinite loops.

Perhaps surprisingly, it is possible to write functions that recurse infinitely without running out of stack space, though it does require some care. It requires the use of a special form of recursion called tail recursion.

A tail recursive call (or, more broadly, a tail call) is a function call that is the last act that a function will perform; whatever that function call returns, its caller will also return, with no further calculations done.

Tail calls allow an important optimization. A normal function call requires a new activation record to be pushed on to the run-time stack, carrying a variety of information, including the parameters, local variables, and return address. Tail calls can be handled differently; when a function f makes a tail call to a function g, the new activation record for g replaces the activation record for f, since f will have no more work to do after g returns. Recursion using only tail calls (i.e., tail recursion) can run infinitely, since the stack space used does not grow as the recursion deepens.

Tail calls are also faster than non-tail calls, which makes tail recursion an important approach in practice, even when you expect recursion to be relatively shallow.

It should be noted that not all programming languages optimize tail calls. Java is a notable example of a language that does not, though this may someday change. But for a language that performs this optimization, it's worth paying attention to. Some things in Erlang absolutely require it; for example, we'll soon be writing potentially long-running servers as single, infinitely-recursive functions, which would soon run out of stack space if they aren't tail recursive.

The following module demonstrates two versions of a factorial function: one that uses tail recursion and one that does not.

    -module(factest).
    -export([fac/1, factail/1]).

    
    % A non-tail-recursive version
    fac(0) -> 1;
    fac(N) -> N * fac(N - 1).

        
    % A tail-recursive version
    factail(N) -> factail(N, 1).
    
    factail(0, Product) -> Product;
    factail(N, Product) -> factail(N - 1, N * Product).

---

Concurrency

Thus far, there is probably little about Erlang that you haven't seen before in at least one programming language, even if you haven't seen very many of them. Where Erlang really shines, and where it delves into territory that will be less familiar and more mind-opening, is its built-in support for concurrency, which allows you to easily write programs that are capable of doing more than one thing at a time. This is important for at least a couple of reasons:

• If you intend to run your program on a machine with multiple processors — a scenario that has, and will continue to, become increasingly common — it becomes necessary to write your program so that it can do more than one thing at a time.
• Even if you don't have a lot of cores, concurrency provides a nice way to break up a complex program into a set of separate, simpler tasks.

Lots of programming languages support concurrency in one way or another. Erlang is very particular in how it supports it. An Erlang program is a set of concurrently-running processes. Processes are entirely isolated from one another, sharing no memory at all; they communicate with one another, when necessary, by sending messages to one another. Processes communicate the same way if they are all running on one machine or if they are running on many machines spread across the Internet; Erlang hides virtually all of the details about how the processes communicate, which makes building distributed systems not much harder than building concurrent ones that run on a single machine. Erlang also provides other important mechanisms, such as the ability for one process to know that another one has died, which is the backbone of fault-tolerance, the ability for a system to systematically and swiftly react to what would otherwise be catastrophic problems.

Note that Erlang's flavor of concurrency is very different from the one available in Java. Java programs are a set of running threads. Each thread has its own run-time stack, but all threads share the same heap; in other words, all objects are shared. This makes it necessary to carefully coordinate access to these objects, understanding which objects are actually being shared and which happen to be isolated (implicitly, since only one thread happens to touch them); access to those that are shared must be carefully synchronized, so, for example, they won't become corrupted if modified simultaneously by multiple threads. This kind of synchronization turns out to be difficult to get right, which is one of the reasons why Erlang's model of concurrency is so attractive; it promises a simplicity that's often impossible to achieve in Java.

---

Spawning a new process

When we want to run a function concurrently with other functions, we spawn a new process to execute that function. The new process runs until the function completes — either normally or due to an error — at which time it dies.

Spawning a new process can be done by calling the spawn function. There are a few variants of the spawn function, but the simplest one takes a fun as an argument and executes that fun in a new process. Here's an example:

    1> WaitAndPrint = fun() ->
                          timer:sleep(5000),
                          io:format("Hello!~n")
                      end.
    2> spawn(WaitAndPrint).
    <0.33.0>

After calling spawn, you'll notice that you immediately get the next prompt from the interpreter, which is ready and able to accept additional expressions from you. Meanwhile, in the background, the WaitAndPrint fun is executing. Notice a couple of things about the WaitAndPrint fun:

• It consists of two expressions, separated by commas. This is legal in Erlang and is useful for situations like this, where functions have side effects, but also for taking complex expressions and breaking them into separate ones with results stored in local variables.
• The timer:sleep function pauses the process that calls it for the given number of milliseconds; the process won't be able to do anything for that length of time. Our call here will pause the calling process for five seconds. Note that no other processes will be affected; they'll still be able to continue processing expressions as normal.
• io:format is analogous to System.out.format in Java; it prints formatted output to the console. The ~n placeholder means "newline character."

So even though we're sleeping for five seconds, the interpreter will still accept expressions as input. Why? Because the interpreter process is separate from the one we spawned; they're running concurrently.

After five seconds, no matter what we're doing in the interpreter, we'll see the text Hello! pop up in the interpreter window. Granted, seeing text pop up in the interpreter, colliding with other text you're typing, isn't especially convenient. But if processes are doing other kinds of things, like writing files, communicating across networks, or drawing graphics in isolated windows, this kind of concurrency becomes very handy indeed.

---

Pids, mailboxes and message passing

Concurrent processes are of relatively limited use if they are isolated from one another and have no means of interacting. While there is wisdom in trying to limit the amount of interaction when possible, some interaction is necessary, just as it's usually necessary, when you hire people to work for you, that they communicate with each other (and with you) at least some of the time.

Though Erlang processes are isolated from one another, in the sense that they share no memory, they are capable of sending messages to one another. This section details the mechanisms that are needed for message passing.

Pids

In the example above, notice that the call to spawn returned the value <0.33.0>. Every process has a unique process identifier, or pid, associated with it. The pid associated with the process we created in the example above was <0.33.0>. (You may notice a slightly different return value when you run this code, as you won't always get the same pid back when you create a process, but the value will have a similar structure.)

The syntax <0.33.0> is the printable representation of a pid in the Erlang shell, but it does not literally build a pid in Erlang. There is a built-in function called pid that does; for example, pid(0, 33, 0) would return the pid <0.33.0>.) However, it will most often be more convenient to store pids in variables, pass them as parameters, etc. For example:

    1> WaitAndPrint = fun() ->
                          timer:sleep(5000),
                          io:format("Hello!~n")
                      end.
    2> Pid = spawn(WaitAndPrint).
    <0.33.0>
    3> Pid.
    <0.33.0>

Mailboxes

Every process has its own mailbox, which collects messages sent to that process. As messages are received by a process, they are removed from the mailbox. In order to make use of mailboxes, we'll need to learn two things: how to send messages and how to receive them.

Sending a message to a process

The simplest way to send a message to a process is to use its pid. The ! operator is used to send a message to a process. It is a binary operator, with the pid of the receiving process on the left-hand side and the message on the right-hand side. Messages are not special; a message can be any Erlang term (i.e., any Erlang data structure, such as a number, an atom, a list, a tuple, a fun, etc.).

Continuing the previous example:

    4> Pid ! 35.
    35

This expression sends the message 35 to the process we created previously.

One important thing to understand about sending messages is that it will never appear to fail, so long as we place a pid on the left-hand side of the !. If the pid is not associated with any currently-running process, the message will quietly be lost. There will also be no notification provided when the other process receives the message. We say that this kind of message passing is fire and forget, meaning that we send messages with little regard to whether they'll get to where they need to go. (That said, we can build our own mechanisms for checking whether messages were received, such as expecting receivers to send us responses. But no such mechanism is automatically provided.)

Receiving a message from a process' mailbox

A process receives one message from its mailbox using the receive expression. The general structure of a receive expression is:

    receive
        Pattern1 ->
            Expressions1;
        Pattern2 ->
            Expressions2;
        ...
        PatternN ->
            ExpressionsN
    end

When a receive expression is evaluated, the first message in the process' mailbox is removed and matched against the patterns in the order they're listed, using the same kind of pattern matching that's done on function arguments and by the = operator. The expressions corresponding to the first pattern that matches the message are evaluated, with the result of the receive expression being the result of the last corresponding expression.

If there are no patterns that match the first message, the second message is tried, then the third, and so on, until a message matches a pattern. If no messages match any patterns (or if there are no messages in the mailbox at all), the receive expression blocks the process until a matching message arrives. By "blocks," I mean that the process will not be able to do any additional work until a message arrives that matches one or more of the patterns in the receive expression.

Example:

    1> Pid = spawn(fun() ->
                       receive
                           hello ->
                               io:format("Hello!~n");
                           goodbye ->
                               io:format("Goodbye!~n");
                           _Other ->
                               io:format("Unknown message~n")
                       end
                   end).
    <0.53.0>
    2> Pid ! goodbye.
    Goodbye!
    goodbye

Expression 1 spawns a new process, executing a function that expects one of three kinds of messages: the atom hello, the atom goodbye, or anything else (note the underscore at the beginning of the variable name, which is a way of saying "I don't care what this value is"). Expression 2 sends the goodbye message. Notice that the spawned process prints Goodbye! to the output in response.

Receive with timeout

A variant of the receive expression supports a timeout, so that a process won't be blocked indefinitely if no messages arrive. This variant looks like this:

    receive
        Pattern1 ->
            Expressions1;
        Pattern2 ->
            Expressions2;
        ...
        PatternN ->
            ExpressionsN
    after TimeInMilliseconds ->
        TimeoutExpressions
    end

The only difference between this variant and the previous one is that it will evaluate the TimeoutExpressions if no message arrives before the given timeout, with the result of the receive expression being the result of the last of the TimeoutExpressions.

---

Process registration

Pids can be inconvenient to deal with, since it is often necessary to pass them to many processes and store them. For this reason, Erlang offers the ability to register a process. Registering a process is to associate it with an atom that functions as its name. Once a process is registered, its registered name is available globally to all other processes; other processes can send messages to it using its registered name instead of its pid. Example:

    1> register(handler, spawn(fun connection_handler:handle_connection/0)).
    true
    2> handler ! 35.
    35
    3> unregister(handler).
    true

Expression 1 spawns a new process and registers it with the name handler. Expression 2 sends the message 35 to that process. Finally, Expression 3 unregisters handler, making that name available to other processes; only one process can be registered with a particular name at any given time.

---

That's it? Where can I learn more?

This concludes the Erlang tutorial. Note that we haven't covered the entire Erlang language, nor have we covered every detail of the features that we've discussed. If you'd like to learn more, there are a few places you can go.

• Of course, we'll cover several detailed code examples in lecture, which will be posted here on the course web site afterward.
• If you're interested in reference material, there is a fair amount of documentation available at erlang.org's documentation page and also at erldocs.com.
• If you're interested in a much more thorough book on the subject, there is a wonderful, free online book titled Learn You Some Erlang for Great Good, which, despite its peculiar title, is an excellent book.