Errata

"A function that takes a fun as an argument is called a higher-order function."

should be either

"A function that takes a fun as an argument OR RETURNS A FUN is called a higher-order function."

(Erlang specific) or

"A function that takes a funCTION as an argument OR RETURNS A FUNCTION is called a higher-order function."

(general).

Note from the Author or Editor:
That's right. Should read "A function that takes a function as an argument or returns a function as result is called a higher-order function."

The second sentence: The base is an integer between 2 and 16, ...

It should be: The base is an integer between 2 and 36, ...

1> 36#zz.
1295
2> 37#zz.
* 1: illegal base '37'

In the first paragraph of the "Atoms" section, erlang atoms are compared to "enums" in Ruby. However, I do not believe that Ruby has enums. I am an Erlang novice; however based on my experience working through the book's examples, Erlang atoms strike me as being very similar to Ruby *symbols*.

Note from the Author or Editor:
I am not a Ruby expert, but after reading this introduction to Ruby symbols, http://www.troubleshooters.com/codecorn/ruby/symbols.htm it's clear that they are not exactly the same as Erlang atoms. Probably the best thing here is to remove all comparisons to Ruby constructs.

Replace line numbered 10 by

10> {Elem, Elem, X} = {1,2,3}.

3. pp36, Variable names, Name and Surname in command 15,
Since the command numbers are sequential, we should
naturally think that Erlang shell is used contiguously.
The variables "Name" and "Surname" are bound in command 12,
and no variable flush (f()) is called. So, In command 15,
"Name" and "Surname" can not freshly bound, but should be
match error.
The variable name in command 15 should be changed, or
command line should be re-initialized.

Note from the Author or Editor:
Suggestion:

change the next to last line on p36 to
15 {person, N, S} = Var.
ALSO
change line 3 of p37 to read
N being bound to the string "Francesco" and the variable S to "Cesarini".

NOTE that in this line the words
N, "Francesco", S, "Cesarini"
should all be in typewrite font

BEAM in fact stands for Bogdan's Erlang Abstract Machine, as it was devised by Bogumil (Bogdan) Hausman. In recent years Bjorn has taken on the implementation of the VM. Thanks to Bjarne Dacker for this correction.

The general case expression is illustrated in a wrong way. It should look like this:

case conditional-expression of
Pattern1 -> expression11, expression12, .. ;
Pattern2 -> expression21, expression22, .. ;
...
Patternn -> expressionn1, expressionn2, ..
end

Note: the current illustration in the book suggests as if the same expression1, expression2, ... should appear for all the Patternis. (What apparently makes no sense.)

Moreover there is a typo in the second line:
Pattern1 -> expression1, expression2, .. ;,
The ',' should be removed from the end.

4. pp46, general case expression's form. TYPO
The extra comma at the end of first pattern (Pattern1)
should be deleted.

Note from the Author or Editor:
Already noted at the end of an earlier erratum entry, but this makes it a separate issue.

When explaining the 'if' construct, you illustrate the example with guard expressions numbered from 1..n and expressions numbered 1 to (unknown) - yet in the bottom line on that page you reuse the variable 'n' to illustrate that all expressions that match the 'Guard_i' expression will be executed. Under a strict reading, using conventional matrix math notation, one might interpret that to assume that only as many expressions will be evaluated as there are guard conditions (since the variable 'n' is reused). It'd be better to use the conventional "m x n" notation - i.e. Guard_1 .. Guard_m, and expression_1 .. expression_n.

Thanks.

Note from the Author or Editor:
change the last letter on the page from "n" to "m"

Once it mentiones 'now/1' instead of 'now/0'.

'This helper function takes two accumulators, one used to store the sum
and the other to store the average.' --- the other accumulator in fact
stores the length, not the average. The rest of the text in that
section correctly refers to the 'length' accumulator.

The text refers to an error that can occur "when you match to retrieve parts of a result from a function call".
But the code shows different kind of scenario, not involving function calls.

Note from the Author or Editor:
Yes, the example code should be replaced by

1> lists:keysearch(1,1,[{1,2},{2,4}]).
{value,{1,2}}
2> lists:keysearch(3,1,[{1,2},{2,4}]).
false
3> {value,Tuple}=lists:keysearch(3,1,[{1,2},{2,4}]).
** exception error: no match of right hand side value false

this line should read
-export([return_error/1,try_return/1,try_wildcard/1,try_return2/1]).

The caution warns that the arguments passed to the spawn function have to be a list, and compares two code sections as follows:

-------------------
"spawn(m, f, [a])"

Not

"not spawn(m, f, a)".
-------------------

The "not" in the second line of code should not be there. It should instead read as follows:

------------------
"spawn(m, f, [a])"

Not

"spawn(m, f, a)"
------------------

"where Frequencies is the loop data containing a tuple of allocated and available frequencies"
This is the wrong way round wrt code, and would be minor if you had not stated it the right way round in para 1 above?

The module in this example is called "server", but there is a call to spawn/3 with "generic_handler" as the module name. This can be found on page 125, last line.

Note from the Author or Editor:
To fix this, replace last line on p125 by
Pid = spawn(server, init, [Data]),

Line that reads "Pay particular attention to the send_event/2 call" should read "Pay particular attention to the event/2 call".

isn't the Pid in the exit signal,{'EXIT', Pid, Reason}, generated by exit/2 the pid of the exit/2 caller? (based on Joe Armstrong's book page 155 and my own experiment)

Note from the Author or Editor:
Correct, the Pid generated by the exit/2 is the Pid of the caller, and not the Pid of the receiving process.

Figure 6-7 needs updating, there the calling Pid is called PidA, the crashing Pid PidB. The exit/2 call should be exit(PidB, Reason) and the message itsself {'EXIT', PidA, Reason}.

allocate can allocate multiple frequencies per client, deallocate deallocates only one and always unlink the pid. This way if you allocate two frequencies and deallocate one, client and server will be unlinked. deallocate should check it's going to delete the last allocate frequency for that client.

Note from the Author or Editor:
This is a good point. There's an implicit invariant that each client will only ask for a single frequency, but this observation is right in the case where the invariant is broken.

"the synchronous client function stop/0" should be changed to "the synchronous client function stop/1"

try .. catch will not add anything here, as we are trapping exits. link will work, and an exit signal with reason noproc will be sent to the process.

Note from the Author or Editor:
The paragraph should read:

In the first version of this exercise, use the link(Pid) BIF. Make sure you handle the case where a process you are linked to terminates before you unlink from it.

This line should be
-export([test1/0, test2/0]).
rather than
-export([test/1, test/2]).

The shell statement numbers 5 and 6 indicate that the user is to continue their shell session. However, executing these commands in the same shell session results in an error.

The problem is that there was no fully-qualified call from the loop process to load the third version (that has a fully-qualified call to a/1). And since statement 5 compiles the v3 of the module, the version being run by the process (v1) has been unloaded, the process dies, and the statement in line 6 fails because foo is no longer the registered name of a running process.

Note from the Author or Editor:
You are correct. The text should read:


the effect of the same software upgrade will be evident after recompilation in command line 4, where we change a(N) -> N + 2. back to a(N) -> N. When trying it out in the shell, make sure you start with a new one so as to avoid side effects from the old module versions of the previous examples:

1> c(modtest2).
{ok,modtest2}
2> modtest2:main().
true
3> modtest2:do(99).
101
4> c(modtest2).
{ok,modtest2}
5> modtest2:do(99).
99

Technically speaking, this is not definition of positive function, it's a definition of non-negative function. In that regard the "true" result of lists:all(Positive, [0,1,2,3,4]) in shell line 20 might be misleading.

Note from the Author or Editor:
In the lines numbered 18, 19, 20 and 21 change all occurrences of "Positive: to "NonNegative"

The usage of the terms 'binaries' and 'bitstrings' is not consistent.

Throughout the chapter the terms binary/binaries are often used where bitstring/bitstrings would be correct.

As bitstring is the more general type, and binary is a "subtype" of it, applying only to bistrings where bit size is a multiple of 8.

Note from the Author or Editor:
Thanks! We will take a careful look for the next iteration.

The statement

<<X:7/binary,Y:1/binary>> will never match...

is just not true!

e.g. the following extract from the shell shows that it will match:

1> <<X:7/binary,Y:1/binary>> = <<1,2,3,4,5,6,7,8>>.
<<1,2,3,4,5,6,7,8>>
2> X.
<<1,2,3,4,5,6,7>>
3> Y.
<<

Note from the Author or Editor:
Thanks very much for sorting out this confusion on our side.

Incorrect arity of prettyIndex and prettyIndexNext functions. They must be prettyIndex/0 and prettyIndexNext/2.

Note from the Author or Editor:
The reason for this was a change in the interface - whether or not to pass the table id - which has not been completely implemented.

Change line
The traversal is set up by prettyIndex/1, which reads the first field, {Word,N}, and builds
to
The traversal is set up by prettyIndex/0, which reads the first field, {Word,N}, and builds

Change line
are passed to the worker function prettyIndexNext/3, which performs the traversal:
to
are passed to the worker function prettyIndexNext/2, which performs the traversal:

Also on p223, change line
prettyIndexNext(TabId,Entry,{Word, Lines}=IndexEntry) ->
to
prettyIndexNext(Entry,{Word, Lines}=IndexEntry) ->

the first line of the code block should read
prettyIndexNext(Entry,{Word, Lines}=IndexEntry) ->
rather than
prettyIndexNext(TabId,Entry,{Word, Lines}=IndexEntry) ->

Node name mix-up.

Is:
(beta@STC)2> nodes(connected).
['beta@STC']

Should be:
(beta@STC)2> nodes(connected).
['alpha@STC']

before the line
-export([start_link/0, start_link/1, stop/0]).
insert the line
-module(usr).

supervisor:start/3 and supervisor:start/2 don't seem to exist.

Note from the Author or Editor:
Yes, indeed. Should make the following edits on 276

1. delete the lines
supervisor:start(ServerName, CallBackModule, Arguments)
supervisor:start(CallBackModule, Arguments)

2. modify the line
You start a supervisor using the start or start_link function:
to
You start a supervisor using the start_link function:

3. Modify the line
functions of arity two.
to
function of arity two.
from this page.

and at the top of p277 should change

Note that the supervisor, unlike the gen_server, does not take any options. The start and start_link functions will spawn ?

to

Note that the supervisor, unlike the gen_server, does not take any options. The start_link function will spawn ?

The text describing child restart strategy transposes the meanings of 'temporary' and 'transient'.

The erroneous text reads : "Transient processes are never restarted. Temporary processes are restarted only if..."

It should read : "Temporary processes are never restarted. Transient processes are restarted only if..."

The function systools:make_rel(Name, Options) and systools:make_rel/2 is depreciated and should be replaced with systools:make_script(Name, Options) and systools:make_script/2

Note from the Author or Editor:
make_rel functions should be replaced with systools:make_script/2. systools:make_rel is depreciated.

just the brackets missing at the when(..) and f.send!(...) and it works like a charm in ruby 1.8.7 with current gem of erlectricity

require 'rubygems'
require 'erlectricity'
require 'stringio'

def fac n
if (n<= 0) then 1 else n*(fac(n-1)) end
end

receive do |f|
f.when([:fac, String]) do |text|
n = text.to_i
f.send!([:result, "#{n}!=#{(fac n)}"])
f.receive_loop
end
end

Thanks very much to Mark Jones for pointing this out.

Text says: "dbg:stop/0 will not clear the trace flags"

According to Erlang docs, dbg:stop/0 does clear the trace flags. dbg:stop_clear/0 is the same as dbg:stop/0, but also clears trace patterns.

Note from the Author or Editor:
Modify the final line to say:
not clear the trace patterns. For this purpose as well as clearing the trace flags, use dbg:stop_clear/0.

The book does not mention that to be able to use TypEr, you first have to create a Persistent Lookup Table with Dialyzer. Adding this information may be difficult, as TypEr is presented before Dialyzer.

Also page 401 says that generating the PLT takes some minutes. On our Sun workstation it takes about 2 hours and Dialyzer gives no indication of progress, giving the impression of having crashed.

Note from the Author or Editor:
Good point! We should look again at the order of this material.

The text warns that if you do not handle unknown messages, "you will notice that the CPU usage of your system will start to increase and that the response time will decrease". The explanation is that Erlang will have to traverse an increasing amount of messages waiting in the process's mailbox. But if that's the case, won't that increase the response time rather than decreasing it? Decreasing the response time means Erlang will perform faster rather than slower...

Note from the Author or Editor:
Yes ? we should have said that the responsiveness will decrease, because the response time will increase.