1. Erlang is unique because it models computation as a network or concurrent processes, mimicking things happening in parallel in the world.

A process is anything that for which these assertions are verified:

1. it has addresses ;
2. sending a message to any of its addresses causes it to receive this message ;
3. it has a state ;
4. given a message and its state, it can perform computations ;
5. it can update its state ;
6. it can send messages to addresses it knows about (and thus other processes) ;
7. it can create other processes.

1. In a computer, a Core is a physical piece of hardware that can execute machine code that implements an ISA.

1. Programming in Erlang involves expressing computations in terms of processes interlinked by message passing.
2. Erlang provides a way to define these processes in its language, then maps the process instructions to machine code instructions, distributing them across the cores while maintaining the guarantees of the processes.

1. As a function \text{f} : \text{Message} \times{} \text{State} \rightarrow{} \text{State} \times{} \text{Message}
2. let f(\text{message},\text{state}) = (\text{state'}, \text{message'}) means that the process updates its state from \text{state} to \text{state'} and sends the message \text{message'} as a consequence of being in the state \text{state} when receiving the message \text{message}.

1. By writing a module i.e. a text file in the Erlang language.
2. This file is compiled down to Erlang bytecode and then to machine code where the actual computations occur on the hardware.

• The BEAM is a virtual machine that executes BEAM bytecode.
• A detailed description of the BEAM is given here.
• The bytcode is described here.

1. Write a module. For instance: -module(person). -export([init/1]). init(Name) -> … .
2. the expression: Joe = spawn(person,init,["Joe"]) builds a process which behaviour is specified by the module person and started using the person module public procedure init with the value "Joe"
3. The expression: Joe is the address — PID in Erlang terms — of the associated process such that: Joe ! {self(), "Hello!"} sends the message {self(), "Hello!"} to Joe where self() is the PID of the current process sending the message.
4. For Joe to reply, the person module should be completed with: -module(person). -export([init/1]). init(Name) -> receive {From, Content} -> … end. which allows Joe match the address sent with From and the content with Content.

Given N processes and M cores, distributing the processes accross the cores in order the optimize cores utilization is called process concurrency. At a given time t if processes p1 and p2 are executing in two different cores, then they execute in parallel at t.

• Performance: if a program is implemented in terms of processes, then: it is easier to map it to many cores than a program written sequentially.
• Scalability: more cores and memory means that processes are mapped automatically to a greater amount of resources.
• Fault tolerance: if a process crash, it is hard to crash the whole network of processes since processes do not share memory.
• Clarity: since things happen in parallel in the real world, it is easier to map things to processes executing concurrently.

No. This process is inherently hard and cannot be automated.

Specification:

1. Let s = self()
2. A file server is a process p = file_server:start(ADir).
3. p ! {s, list_dir} causes s to receive a list of files in ADir.
4. p ! {s, {get_file, "a_file.txt"}} causes s to receive the content of "a_file.txt" in ADir, if any.

Implementation:

Specification:

1. Given a file server fs, a client may use fs sequentially. For instance: … FS = file_server:start(ADir). FileList = file_client:ls(FS) … without having to be aware of the communication protocol.

Implementation:

1. If X is un unbound variable, then: X = 123 means that X refers to the value 123 after which it cannot be assigned an other value again.
2. More generally, it means evaluate Y and match it to X.

A concurrent program means many processes, maybe millions of them: an error localized to one process is not that important compared to an error in a sequential program where you have one process. In one case, an error will have a much harder time taking down the whole program than the other.

One of these three outcomes:

1. The function never returns.
2. The function returns.
3. An exception is raised.

The caller may set a timeout after which an exception is raised.

The caller must do something in case an exception is raised.

In a sequential program, it may look like so: for a client calling f, it may be conceptually equivalent to: y = call(f, x, 5, error_handler) which means: call f on x. If it does not return under 5 seconds, raise a timeout exception. If an exception err is raised, call error_handler(err). Else: return the value and bind it to y.

In a concurrent program, we just let it crash.

1. Fail as soon as possible.
2. Fail withe a meaningful message.
3. The message should be written to a persistent error log.
4. Only the programmer should see the error report, not the user.
5. You should describe the behavior of functions only for valid input arguments;
6. all other arguments will cause internal errors that are automatically detected;
7. You should never return values when a function is called with invalid arguments;
8. You should always raise an exception.
9. Assume that the caller will fix it.

1. exit(Why)
2. throw(Why)
3. error(Why)

catch all possible errors using this syntactic construct:

1. try…catch…after…end

The loop should have a clause that matches all messages and act accordingly, else: messages stay in the mailbox.

1. When we enter a receive statement, we start a timer (but only if an after section is present in the expression).
2. Take the first message in the mailbox and try to match it against Pattern1, Pattern2, and so on. If the match succeeds, the message is removed from the mailbox, and the expressions following the pattern are evaluated.
3. If none of the patterns in the receive statement matches the first message in the mailbox, then the first message is removed from the mailbox and put into a “save queue.” The second message in the mailbox is then tried. This procedure is repeated until a matching message is found or until all the messages in the mailbox have been examined.
4. If none of the messages in the mailbox matches, then the process is suspended and will be rescheduled for execution the next time a new message is put in the mailbox. When a new message arrives, the messages in the save queue are not rematched; only the new message is matched.
5. As soon as a message has been matched, then all messages that have been put into the save queue are reentered into the mailbox in the order in which they arrived at the process. If a timer was set, it is cleared.
6. If the timer elapses when we are waiting for a message, then evaluate the expressions ExpressionsTimeout and put any saved messages back into the mailbox in the order in which they arrived at the process.

Use the register API.

If this process dies, we might be in deep trouble since no other process can help. For this reason, sequential languages have concentrated on the prevention of failure and an emphasis on defensive programming.

The failure of any individual process is not so important. We usually write only a small amount of defensive code and instead concentrate on writing corrective code. We take measures to detect the errors and then correct them after they have occurred.

1. Remote detection and handling of errors
2. Instead of handling an error in the process where the error occurs, we let the process die and correct the error in some other process.
3. When we design a fault-tolerant system, we assume that errors will occur, that processes will crash, and that machines will fail.
4. Our job is to detect the errors after they have occurred and correct them if possible.
5. Let it crash
6. Let some other process fix the error
7. We cannot make fault-tolerant systems on one machine since the entire machine might crash, so we need at least two machines. One machine performs computations, and the other machines observe the first machine and take over if the first machine crashes.

1. We build our applications in two parts: a part that solves the problem and a part that corrects errors if they have occurred.
2. The part that solves the problem is written with as little defensive code as possible; we assume that all arguments to functions are correct and the programs will execute without errors.
3. The part that corrects errors is often generic, so the same error-correcting code can be used for many different applications. For example, in database transactions if something goes wrong in the middle of a transaction, we simply abort the transaction and let the system restore the database to the state it was in before the error occurred. In an operating system, if a process crashes, we let the operating system close any open files or sockets and restore the system to a stable state.

1. It means that if one of the two dies, then: the other will receive its death message.

1. LinkSet(P) : Set of processes linked to P

1. If B terminates, then: A receives a down message from B.

1. If any process in A U LinkSet(A) terminates or crash, then: error signals are exchanged, else: messages are exhcnaged.

1. Normal processes and system processes.
2. system processes can trap exit signals but not normal processes.
3. process_flag(trap_exit, true)

If the reason is not normal, it will terminate.

Send him a kill signal: exit(Pid, kill)

1. Just link them.
2. If one dies, then: it sends error signals are sent to its LinkSet.
3. If they are not system processes, then: they die too.

1. If one process in the LinkedSet is a system process, then: it can trap exit signals.
2. Since it traps exit signals, it does not die and does not propagate death.

1. Distributed Erlang applications run in a trusted environment
2. Since any node can perform any operation on any other Erlang node, a high degree of trust is involved.
3. Typically distributed Erlang applications will be run on clusters on the same LAN and behind a firewall, though they can run in an open network.

1. Socket-based distribution
2. Using TCP/IP sockets, we can write distributed applications that can run in an untrusted environment.

1. By using two new operations:
2. Start a new Erlang node.
3. Perform a remote procedure call on a remote Erlang node.

1. Write and test a program in a regular nondistributed Erlang session
2. Test the program on two different Erlang nodes running on the same computer.
3. Test the program on two different Erlang nodes running on two physically separated computers either in the same local area network or anywhere on the Internet.

1. We might use C for efficiency.
2. we might want to integrate a library written in Java

1. By running the programs outside the Erlang virtual machine in an external operating system process.
   • If the foreign language code is incorrect, it will not crash the Erlang system.
   • Erlang controls the external process through a device called a port.
   • Erlang communicates with the external process through a byte-oriented communication channel.
   • Erlang is responsible for starting and stopping the external program.
   • Erlang can monitor and restart it if it crashes.
2. running an OS command from within Erlang and capturing the result.
3. By running the foreign language code inside the Erlang virtual machine.
   • This involves linking the code with the code for the Erlang virtual machine.
   • This is the unsafe way of doing things. Errors in the foreign language code might crash the Erlang system.
   • Although it is unsafe, it is useful since it is more efficient than using an external process.
   • Linking code into the Erlang kernel can be used only for languages like C that produce native object code and can’t be used with languages like Java that have their own virtual machines.

1. The process that created the port is called the connected process.
2. Erlang communicates with external programs through objects called ports.
3. If we send a message to a port, the message will be sent to the external program connected to the port.
4. Messages from the external program will appear as Erlang messages that come from the ports.
5. If the external program crashes, then an exit signal will be sent to the connected process.
6. If the connected process dies, then the external program will be killed.
7. All messages to the port must be tagged with the PID of the connected process.
8. All messages from the external program are sent to the connected processes.

Open Telecom Platform.

1. OTP behavior.

1. An abstraction solves a problem.
2. To build an abstraction, we need to separate functional and nonfunctional parts of the problem.
3. Building an abstraction is a trial and error iterative process.

Specification

1. if:
   1. init : State
   2. handle : Message × State → Message × State
2. then: s ≡ Server(init,handle) : Server
   1. A server s is a process.
   2. It has a state state(s) : State.
   3. Given a message m with a content content(m), it computes handle(content, state) = (state', m'): Message × State
      1. If possible, m' is sent back to the client.
      2. Its state is updated to state'.

Implementation

Usage example:

1. Any ≡ Request
2. Any ≡ Reply
3. Any ≡ Message
4. Any ≡ Reason
5. init : Any → State
6. handle_call : Request PID State → reply × Reply × State
   • synchronous calls
7. handle_cast : Message State → noreply × State
   • asynchronous calls
8. handle_info : Message State → noreply × State
   • messages not sent with call or cast
9. terminate : Reason State → ok
10. code_change : ??? → ???

1. A process that produces prime numbers.
2. A process that computes areas.
3. A supervisor to recover production when it crashes.
4. A logger that will persist error reports to fix production crashes.
5. Alarms to detect, for instance, overheating CPUs.

By packaging it into an OTP application.

1. An event is a piece of data that is built when something notworthy happens.
2. When an event happens, one may just tell the world about it: EventHandler ! {event, E}

1. Given an event evt, the system may change its associated behavior at runtime.
2. In most programming language, the code that will get executed in reaction to evt is statically or dynamically linked.
3. Everything else being equal, if the code executed is represented by: code(t, handler(evt)) at a time t, then: code(t, handler(evt)) = code(t+1, handler(evt))
4. In Erlang, it may not be the case.
5. code(t+1, handler(evt)) may have been hot loaded concurrently at time t.
6. In other words: the code associated with the processing of evt may be changed without stopping the system.

1. You want your system to work as expected.
2. Things go wrong.
3. You want to fix the minimal amount of code to make it right.
4. Errors should give you enough insight into what went wrong to do exactly that.
5. Think of it as a medical doctor that uses symptoms to posit a diagnosis and finally offer an efficient cure.

1. Programmer: to log an error, which procedure to call?
2. Configuration: where and how the error logger stores data?
3. Report: how to analyse the errors?

1. If the system is started with erl -boot start_clean (i.e. dev mode), then: simple logging is done.
2. If the system is started with erl -boot start_sasl (i.e. prod mode), then: error logging is more involved..

1. Using a configuration file so that we do not need to remember configuration arguments when implementing the system.

In the Erlang shell.

1. Supervisor report
2. Progress report
3. Crash report

1. The supervisor is a process that monitors a tree of processes.
2. It is the root of the tree.
3. When a process fail, it may restart it, depending on some configuration.

1. one_for_one: If one process crashes, it is restarted.
2. one_for_all: If one process crashes, all are terminated and then restarted.

1. It describes an application is such a way that erl can start and stop the application: $ erl -boot start_sasl 1> application:load(appname) 2> application:start(appname) 3> application:stop(appname) 4> application:unload(appname)

Erlang view of the world is that everything is a process and that processes can interact only by exchanging messages

1. By using middle men.
2. A Web server may receive {get, Page} and may reply with a String.
3. Exterior requests may take the form of HTTP for TCP connections.
4. Translating from HTTP requests to Erlang terms must be done somehow.
5. A middle man may take this job.
6. For each protocol, a middle man may execute the translation.
7. The server statys the same.
8. In other words, the middle man transforms an N × M problem into an N + M problem.
9. It's like a world where everybody speaks English (or Mandarin)—it's much easier to communicate.

1. It means Mod:Func(A1, A2, …, An, X)
2. Given: -module(counter). -export([bump/2, read/1]). bump(n, {counter,k}) -> {counter, n + k}. read({counter, n}) -> n. then: $ erl 1> c(counter) 2> x = {counter, 2} 3> x:read() 2

1. The Adaptor Pattern.
2. If kv_adapter is implemented using the adapter pattern, then: it may use different implementations to store the key/value pairs using the same interface. -module(kv_adapter_test). -export([test/0]). -import(kv_adapter, [new/1, store/2, lookup/1]). test() -> %% test the dict module M0 = new(dict), M1 = M0:store(key1, val1), M2 = M1:store(key2, val2), {ok, val1} = M2:lookup(key1), {ok, val2} = M2:lookup(key2), error = M2:lookup(nokey), %% test the lists module N0 = new(lists), N1 = N0:store(key1, val1), N2 = N1:store(key2, val2), {ok, val1} = N2:lookup(key1), {ok, val2} = N2:lookup(key2), error = N2:lookup(nokey), ok.
3. Implementation: -module(adapter_db1). -export([new/1, store/3, lookup/2]). new(dict) -> {?MODULE, dict, dict:new()}; new(lists) -> {?MODULE, list, []}. store(Key, Val, {_, dict, D}) -> D1 = dict:store(Key, Val, D), {?MODULE, dict, D1}; store(Key, Val, {_, list, L}) -> L1 = lists:keystore(Key, 1, L, {Key,Val}), {?MODULE, list, L1}. lookup(Key, {_,dict,D}) -> dict:find(Key, D); lookup(Key, {_,list,L}) -> case lists:keysearch(Key, 1, L) of {value, {Key,Val}} -> {ok, Val}; false -> error end.

1. If the programmer can guess what the code does just by looking at the code, then: intentional programming has been correctly implemented.
2. For instance: lookup(Key, Dict) -> {ok, Value} | not_found
3. may be used to fetch a value, search a value and test if a key exists. Instead, better provide this API: dict:fetch(Key, Dict) = Val | EXIT dict:search(Key, Dict) = {found, Val} | not_found. dict:is_key(Key, Dict) = Boolean

Various solutions exist, one of them is rebar.

1. shared state concurrency implies mutable state.
2. mutable state means a region of memory that changes.
3. if multiple processes share state, then: they must coordinate writes to the shared state.
4. In particular, they cannot write to the same region of memory at the same time.
5. In order to prevent this situation to happen, mutexes have been introduced.
6. Mutexes behave like locks on a region of memory.
7. A process p1 locks region R so that only p1 can write to R.
8. When p1 stops writting, it releases R so that others may write.
9. One problem is that, when p1 locks R then crashes, then: R is locked and all other processes are prevented to write: computation stops.
10. An other problem occurs if p1 corrupts the memory: all other processes are sent astray, then do not know what to do.

1. By not having state: there are no mutable data structures so no locks.
2. ⇒ easy to parallelize computations

1. your program must have lots of processes
2. avoid side effects
3. avoid sequential bottlenecks
4. write small messages, big computations code

1. All the CPUs should be busy all the time. The easiest way to achieve this is to have lots of processes.
2. Preferably the processes should do similar amounts of work. It’s a bad idea to write programs where one process does a lot of work and the others do very little.

1. Side effects prevent concurrency.
2. It may lead to concurrent writes to a single memory region leading to the use of mutexes.

1. If one agency sells tickets from a set of tickets, then: the agency is a sequential bottleneck.
2. If two agencies sells tickets, one with odd numbers and the other with even numbers, then: the agencies are guarenteed not to sell twice the same ticket.
3. Replacing the 2 agencies by n(t) agencies that can crash while maintaining the guarentee is an active area of research which goes by the name of distributed hash table.