Historical errata for Programming Erlang

What the text refers as “brackets” should read “parentheses”

I suggest you show lists:foreach/2 before describing list comprehensions — they are a much more well-behaved form of iterating over the elements of a list

(Joe says: I don’t mention funs at all until the next chapter this is deliberate. Too much reorganisation involved and I don’t see the benefit.)

I would strongly urge you to NOT show ==/2 at all — unless you really, really have to. I know that this goes against what the typical C programmer might be familiar with, but please under all circumstances avoid it to compare integers.
Use =:=/2 instead which has much more sane semantics.

“Expresson” —> “Expression”

In the beginning of Section 2.10, I think the most natural example you can show before the one with odds_and_evens/1, is the filter example of page 52, which is (space) efficient using an accumulator instead of the [H|filter()] construct. (Joe says: fixed in a way. Added a sentense about space efficiency in section 2.10)

There is no is_tuple/2 guard.

In mathematics, there is no operator. This is FORTRAN.
Instead of A**2 use A^2 in LaTeX instead.

In Chapter 2 somewhere you should add a table showing all mathematical functions & operators.

In R11B-3, several Erlang processes are allowed do do gen_tcp:accept/1 on the same listen socket. This will simplify making a parallel server, as you can have a pool of pre-spawned processes, all waiting in gen_tcp:accept/1.

I think there is need for a short introduction of Erlang before the Getting Started.
Might also be good to have this on the backcover of the printed book

(Joe says: will discuss in introduction (not yet written))

In chapter 1.1 bullet 5 it says:
5. Compile and run the programs you create in the shell.
This is wrong, you don’t create programs in the shell.
Should rather be something like:
5. Compile and run programs from the shell.

Bullet 2 contains a bad reference
Bullet 4 contains a bad reference
Could you find something better than “programming parallell computers”? Mention multi core processors, SMP systems?
parallell computers sounds abstract and might not automatically point to the current situation with multi core processors where programming Erlang is much better than almost any other language.
Last in stage 2.5 there is a bad reference

Erlang provides an ideal
environment for experimenting with networked applications.
Erlang is not only ideal for experimenting but also for IMPLEMENTING the real networked applications.

Erlang (BEAM) emulator version 5.5.2 [source] … [kernel-poll:false]

Perhaps the line should be skipped including [source] and onwards because it can be misleading (so many different alternatives that we don’t want to explain)

Bullet 1. (This file contains is release 11
version 3).
The “is” is redundant should be removed.

“is we know that X+Y=10 and X-Y=2, then X will be 6 and Y will be 2 in both equations.” should read “if we know that X+Y=10 and X-Y=2, then X will be 6 and Y will be 4 in both equations.”

End of first paragraph under “Pattern Matching” “the result again the pattern Lhs” should be “the result against the pattern Lhs”

Second paragraph under “Pattern Matching”: “Now a variable, such X” should read “Now a variable, such as X”.

The first paragraph of “Creating Tuples” reads, "Tuples are created and destroyed automatically when we declare them
we don

2nd par: “Suppose you want to write program” should be “Suppose you want to write a program”

In the last line on the page, “..beam” should be “.beam”.

In this sentence, “When Erlang sees a statement such as X = 1234. in binds the
variable X to the value 1234.” the ‘in’ should be ‘it’.

Last paragraph of page, first line of paragraph. Currently reads “…build a windows executable one any machine…” and should read “…builds a windows executable on any machine…”

"Here are the results I obtained on the computer I

Footnote has typo “manula” at:

2. io:format understands an extrememly large number of formatting options, the full set can be found in the io manula pages

In th Pattern Matching code you have:
2> Y = 10
10.
3> X = 6.
6.

It should be:
2> Y = 10.
10
3> X = 6.
6

Last paragraph before 1.7 Floating point numbers

you have:
we canimmediately infer

instead of:
we can immediately infer

In C code there is "area(area(struct Shape* s) … is that area duplicate correct?

"Now Let

Variable L is never used and Buy is undefined:

total(L) -> lists:sum([shop:cost(A) * B || {A, B} <- Buy]).

should it be like:

total(L) -> lists:sum([shop:cost(A) * B || {A, B} <- L]).

In the “Pattern Matching” paragraph the second line of the erlang shell is “Y = 10” and should be “Y = 10.” with the full stop.

“Examples or OR-guards” should be “… of OR-guards”

I think the example should be easier to read if the author in the text refers to them as the number indicated by the Erlang shell instead of counting the real numbers since the examples themselves are not provided with line-by-line numbers on the left side.

“Elang” instead of “Erlang” in the first line.

The top of the page says:
“[X || Quantifier1, Quantifier2, …]
X is an arbitrary expression, and each qualifier is either a generator or
a filter. ”

I’m guessing that Quantifier should be changed to Qualifier here.

First sentence after “P = {10, 45}”.

Since the tuple itself is just contains a couple of integers we have to remember what its being used for.

The “is” is superfluous and shouldn’t it be “it’s”?

Third full paragraph on the page: “This is just Width * Height ie 10 * 5 = 20.” “20” should be “50” and possibly “Height” should be “Ht” since that’s what it’s called on the rest of the page.

Second bullet point in the list, “instances of cirlces need not be need not be located”, has an extra “need not be”.

Red is twice in following text: “We decide to allocate 5 bits for the red channel, 6 bits for the green channel, and 5 bits for the red channel.”

Expression 3 in the example at the top, “IsFruit = MakeTest(L).”, L is unbound and I think it should be “IsFruit = MakeTest(Fruit).”

The last example (“>5”) uses a list which hasn’t been introduced.

Shouldn’t you (at least in a footnote) mention Unification when explaining all the stuff about the pattern matching operator?

The first sentence reads a little weird. I think this is a little more easier to read: “We said earlier that what looks like an assignment statement isn’t really an assignment statement at all. Instead, we stated that ‘=’ is a pattern matching operator.”

The binding given for T (on the example list L) is wrong. The first element should be 6 as T is the tail of the list, in the text T is given as binding to the whole list.

“Expr1 andaslo Expr2” should be andalso.

The last paragraph: “‘area’ is made up from two clauses, the clauses are separated by a semicolon, and the final clause is terminated by dot-whitespace.” I think that the first part of the sentence before the first comma should be a single sentence, with the second part being another sentence. Also, I think that the first part should say: “‘area’ is made up of two clauses.”

“is_atom(L) orelse (is_list(L) andaslo length(L) > 2)” should be andalso.

A minor point: In the paragraph, “In this case …”, it says that in the prior example, order of the clauses does not matter. But, while starting to read “In general”, I got a little confused for a second, mainly because there was no “exception” word. I think it should say: “In general, though, clause order does matter …”

Second bullet item: “Erlang is not an object oriented language, this means …” I think that this reads better: “Since Erlang is not an object-oriented language, data structures that create …”.

In Figure 2.1, the indefinite articles are incorrect for many entries (e.g., “X is an list”).

Examples of AND-guards: if “is_tuple(T, 6)” is correct then Figure 2.1 is wrong, because it shows is_tuple(X) where X is an atom.

“The second guard means…OR the absolute value”, not “AND the absolute value”. Might want to reword so grouping is unambiguous. Suggestion: “The second guard means that either (X is an integer and is greater than Y) or the absolute value of Y is less than 23.”

First bullet: “…are written with any special syntax” should perhaps be “…are written WITHOUT any special syntax”.

First paragraph of 3.1: “For example, it’s impossible, to turn…” Remove the second comma.

Last bullet, starting with “none()”: “This is used for a function that never returns has type (…) -> none()” needs to be fixed. Does it never return, or does it have type (…) -> none(), or are those the same things?

In “Expr1 andaslo Expr2” should be andalso.

“Evaluating Mult(3) returns fun(X) -> X * 3, ie the body of the inner fun with Times substituted with 3.”

It looks like in the place of “ie”, it should be “which is”. Or maybe this will give it a different meaning?

3.3, first paragraph: “The Swedish Telecoms company Ericsson” (Where Erlang was developed)…" (A) “Where” should be lower-case. (B) Perhaps “Telecoms” should be “telecom”?

3.3 second paragraph: “Handling errors…very different to handling errors…” should be “…very different FROM handling errors…”

At the top: “As we have seen, using higher order functions we can create …” I think this is missing a word … “As we have seen, when using higher order functions, we can create …”

Item 3.: “…is tying to fix…” should be “…is trying to fix…”

On the top … “since the explanation would be many times tonger then the program,”

Text in the grey box, first paragraph: “might have have forgotten” (duplicate “have”)

A minor point: In the example where Person is set to a new record, I believe “Van Winkel” is really spelled “Van Winkle”. :)

In the fourth paragraph, “In general, lists should always be build by appending elements … ”

I think it should be “built”.

“The next chapter, covers all the remaining details of sequential Erlang.” The comma is extraneous.

In the shell example at the bottom, Y = 10 doesn’t have a period at the end.

Context: Well it turns out that pattern matching is fundamental to Erlang and that it

"Once we

“(called funs)” should probably read “(called *fun*s)”

"Then finally we

The text implies that strings created by the “….” syntax are ASCII encoded this is only kind of true - a strings e.g. "H

“can try an catch” should read “can try and catch”

In Figure 2.3 tail is listed as lt(X)

In the example at the bottom the calculations are wrong. Using the costs defined in shop.erl on page 34, L1 should be [20,8.20,27,21] and lists:sum(L1) should be 123.

In the paragraph starting “Now we split T into two lists”, the criteria “that are less than Pivot” should read “that are less than or equal to Pivot”.

Second paragraph, “where the sum of the sides is less than N” should read “where the sum of the sides is less than or equal to N”

In the explanation of the AND-guard, if " X > Y" is spelled out “X is greater than Y” then “Y < 6” should be spelled out with “less than”.

I don’t think annotions is a word. It’s not in my dictionary, anyway.

First paragraph under “Short-Circuit Boolean Expressions”, “are boolean expression” should read “are boolean expressions”.

The not-object-oriented paragraph makes it sound like being not OO is a benefit, which will be contrary to most people’s background, and does not support it. If that concept is discussed elsewhere it might be good to put a pointer to that here.

The first example

M = <<X:3, Y:5, Z:11>>

gives a badarg because it isn’t divisible by 8.

Might be nice to point out that funs will be powerful stuff. Right now it leaves you wondering “and how is this different from what we just did in the module section?” if you don’t know why first-class functions are important.

In the gray box, paragraph 1: “It’s also a good idea to name rename your functions to make it clear that they return a boolean.”

Which one is correct?

"So if we make sure all our functions which can only
return one of two atomic atomic value return booleans then
we

In “Boolean Expressions”, the first item: “not B1 - Local not”. Looks like it should be “Logical” instead.

A minor point: In 4.3, in the last paragraph, it says that hello.erl will print out “:hello world.”. But the code on the next page instead prints out “Hello world”.

On the bottom, the sentence below “-s init stop”, it read “… evaluates the function it:stop()”. It looks that it should be init

Below the receive example, in the next sentence starting with “This code …”, it says “… otherwise it wait for a message matching …” I think it should be “waits”.

In the last sentence: “something with is very useful”. “with” should be “which”.

In “Extending the Program” in the first sentence after the code there are two successive “doesn’t”.

Extra closing paren: “but this is jumping too far ahead.)”

in “then the code loader with search for a file” maybe “with” should be “will”

“couiple” instead of “couple”

In the text “The binary <<”cat“>> is shorthand for <<9,97,116>>”, the first integer should be 99, not 9.

> Start your favorite text editor and enter the following
> into a file called shop.erl.

This to me is almost always the hardest entry point for anyone into a language. Start your text editor where? From the same directory as Cean? If you do that it doesn’t compile because the Cean start script immediately moves to the bin directory (at least under windows):

> cd erlang/erts*/windows/bin
> start werl.exe

In order for it to compile under the shell I’ve got to place the file in Erlang’s bin directory. Not exactly the place where you want to be storing your src and beam files.

(Joe says: will be addressed in windows appendix)

The introduction to lists is a bit confusing.

The text talks about “Accessing the head of a list is a very ef ficient operation, so virtually all
list processing functions start by extracting the head of a list, doing
something to the head of the list, and then processing the tail of the
list.”

So you naturally assume that when you get to the next item called “Syntax” it will be talking about extracting items from a list. How to do a CAR/CDR.

What Syntax is really talking about is adding items to a list. Which doesn’t seem to fit the flow of the text.

Near the end of the page, in “To pack the memory we just wrote the expression <<Red:5, Green:6, Blue:6>>.” that should be “Blue:5”.

The first paragraph on the page after the list of specifiers begins “I’ve you found…”. It should read “If you’ve found…”

Last paragraph: “…you can cut a MPEG file…” should read “…you can cut an MPEG file…”.

In “We use dthe information”, “dthe” should be “the”.

Bullet number 2: “consequative” should be “consecutive”.

“Consecutive” is misspelled “consequative” in more than one place on this page. Perhaps on other pages as well?

There should be some description on where to put modules such as math4.erl once it is downloaded so that c(math4). works without an error.

At the bottom of the page, you use the syntax “2#11111111111” for a binary number. That syntax isn’t introduced until page 92. Perhaps there could be a brief note after the use on page 77 that explains that “2#” means base two?

In the first paragraph of “Attributes”, “There two types…” should be “There are two types…”

In the first paragraph after the code at the top of the page, square/2 should be square/1.

The text:

“Compiled modules have the extension ..beam”

has two periods before beam.

At the top of the page, the code fragment at prompt 3 is

3> IsFruit = MakeTest(L).

It should be

3> IsFruit = MakeTest(Fruit).

as L is not bound at this point, and Fruit was bound on the previous page

Figure 2.2

Two different forms of equals are introduced. Perhaps add a note explaining the differences between them.

Start of Chapter 3, definition of BIF does not make sense.

I think it should be “but are NOT written”.

lines 5, 6
we know that X+Y=10 and X-Y=2, then X will be 6 and Y will be 2 in both equations. should be
we know that X+Y=10 and X-Y=2, then X will be 6 and Y will be 4 in both equations.

Rather than using the “~n” format specifier, why not simply use “\
”? (This is a general comment for anywhere format specifiers are used.) The advantage of “\
” is that it’s already familiar—one less weird thing for people to balk at—and “\
” works just fine.

The Miscellaneous topics bullet has an extraneous “topics”, it should probably read “This deals with a small number of topics”.

The language in the bullet point for the none() type doesn’t flow well. Perhaps leave off “has type (…) -> none()” or break it into a separate sentence.

In point 2 of the TypeExpression definition, should {X1, X2, …, Xn} be [X1, X2, …, Xn] since it’s a list?

In paragraph “Have we said the final word on map? …” there’s a section reference missing (sect.pmapsect.pmap) and there’s a closing parenthesis to much.

First paragraph, second sentence should read “Is FileName an atom”.

How about sorting the entries in table 2.1 by priority?

decode_header(<<2#111… )

no explaination or reference provided for defining integers in another base. In this case base 2.

Aren’t you mixing the use of “,” and “;” in the “OR-guards” paragraph? Shouldn’t it be “AG1; AG2; … ; AGn” (note the semicolon before AGn) both in the code and the text? Using commas in the text is in this context a bit confusing.

Maybe add a reminder that functions with different arity are entirely different functions. It took me a while to remember when starting at lib_misc.erl

In the last paragraph before the last code sample, final sentence should read “we can try and catch” (or maybe “try to catch”).

In the first sentence after the numbered list, “d(dog)” should be “g(dog)”.

(Joe says: actually, h(dog) :)

“real-world code than uses the bit syntax.”
should be:
“real-world code that uses the bit syntax.”

This means " when…

extra space between quotes and the word when.

(built) by appending elements to the start …

I think it should be prepending elements to the start

Um, how exactly do we do this magic reverse operation? It sounds like there’s a built-in efficient way to do it but then we’re not told how.

Not sure I like the comma in “The bit-syntax, in particular is…”

Is file name an atom, …

2nd line from the top

makfiles

In the paragraph starting with the number 2. spelling error declaired -> declared

In the paragraph starting with the number 1. ‘Is ou’ should read ‘If you’

The example in subsection 4.9 shows typing help() twice. One instance may be remove.

“We use dthe information” should be “We use the information”

“To write an write” should probably be “To write”

“The shop does not sell:socks”

Should probably omit the : or put a space after it

In paragraph 3, in the fourth sentence: “To send a reply
back, the client has to include an address that the sever can reply to.”

Sever should be “server”

Subsection 5.7 (1st paragraph): ‘One the other had’ should be ‘On the other hand’

You use 2#11111111111:11 here, and just 2#11111111111 on the next page. I’m also not sure what _D:1 means.

Subsection 6.4 first line: ‘at the thre concepts’ s/thre/three/

“Lines to match the IP datagram in a single pattern-matching expression.” Is that supposed to be a caption? It’s not a complete sentence. Also, “can be isolated (Lines to ).” doesn’t make sense either.

Extra end: “The value of a begin … end end block”

I think the xml tags, e.g. ‘# ’ aren’t supposed to be there (or perhaps shouldn’t be seen).

“Note that if some symbol X occurs K
times in B then only the first K occurs of X in A will be removed.”

Maybe rewrite as “Note that if some symbol X occurs only K times in B then only the first K occurences of X in A will be removed.”

3rd possibility of distributing code is via the code server
(erl_prim_loader).

Missing period after “Hello world had no arguments”

“In the next chapter we’ll start looking at concurrent programs”, but you don’t cover concurrency until chapter 5.

On the first line, function should be “functions”.

You say “finally, the shell prints out {rectangle, 6, 10}” but it actually printed out {triangle, 2, 4, 5}. Also I think “by defining it as Pid1 ! Pid2 ! … ! M we send…” should use a different word than defining. Maybe, “by writing Pid1 ! …”

In the description of -endif, “ifdef of endif” should be “ifdef or ifndef”.

In the C area function,
area(struct Shape* s) {
if( s->kind = Rectangle){
should be
area(struct Shape* s) {
if( s->kind == Rectangle){

In section 6.2, first paragraph: “We can wrote a function … ”

When creating instance of person record should have
lastName = “Van Winkle”,
instead of
lastname = “Van Winkle”

In the subsection “System Processes”: “When a process receives an exit signal, it too will die *unless it is
special kind of processes* called a system process.”

The first paragraph in Section 6.6: “Suppose we have a large set of parallel processes that are involved in
come computation, and something goes wrong.”

In the “Joe Asks … ” box: “One you understand …”

In the bullet “Socket-based distribution”: "

The first paragraph after the bullet points: “Writing a distributed Erlang program is easy all we have to do …”. After “easy”, it should end with a period.

The second item on the top: “Choose a port or range of ports to be used for distributed Erlang itself, make sure these ports are open)”

The first paragraph of section 7.2: “A complete virtual machine with its own address space and own set of processes.” This is an incomplete sentence.

The example code should be of a more liberal license. Much of it is generally useful and having it under a suspicious “Copyrights apply… blah blah” license does the Erlang community a disservice, since this will surely become the definitive printed language reference for some time.

(Dave says: all code released in the United States has copyright applied to it automatically. The trick is to then allow its use by license (that’s how the GPL works, for example). What rights would you like to see included?

I assume your laptop should have 512 MiB of memory and not kB, unless you’re talking about processor cache?

top: Grammar: should be “Now that you’re comfortable with Erlang…”

“telecoms applications” should be “telecom applications”. Similarly for “non-telecoms applications”

“system dependant” should be “system dependent”

My source tarball is called otp_src_R11B-3.tar.gz, not otp_src_R11-B3.tar.gz.

“operating systemsand” should be “operating systems and”

You should write “is not an observer sport” not “a observer sport”. Even better: “Programming is not a spectator sport.”

Box: You haven’t mentioned what atoms are yet, so you should at least say e.g. “We’ll discuss what atoms are below.”

A lot of the time I won

It would be nice to mention that LHS means “left-hand side” and RHS means “right-hand side”, for the less math-literate.

Say “belaboring”, not “laboring” the point. Or at least that’s how I say it. Also, it should be “arbitrarily complex” not “arbitrary complex”.

If you’re going to mention tuples and lists at all (which is
probably not a great idea here) you should at least say that they represent compound data structures (i.e. with multiple components).

Better grammar: "We must ask ourselves what an error is, and how an error makes itself known.

The discussion of how single-assignment variables make debugging easier is reasonably persuasive, but I think the average programmer will be more concerned by how it’s possible to even write programs like that at all. Obviously, the rest of the book deals with this, but some reassurance that it is in fact possible (as long as you change the way you think appropriately) would be a good thing here.

When I went to school my math teacher said

The expression “(12 + 5)/3.” is misleading; the first time I read it I thought that the “3.” was a floating-point number. Instead, this relies on the fact that division promotes integer arguments to floats. This should be clarified.

“If you’re used to enumerated types… then you will know about atoms” is a bit vague. Better to say “then you have already used atoms whether you realize it or not”.

You mention that Erlang is a functional programming language. I haven’t seen this mentioned before. A brief discussion of this should probably go in the Introduction (which isn’t in the book yet).

(Joe says" this will be in the introduction)

Note that tuples don’t have named fields, unlike structs in C.

The Person tuple should probably have the second to fifth lines indented an extra space to show the structure better.

Don’t say that tuples are destroyed automatically when we declare them! Say that the system manages the memory and destroys them when they are no longer being used. You might mention “garbage collection” here. You might also say “Much like in Java, but unlike in C, we don’t have to worry about memory allocation.”

“Well it turns out” ==> “Well, it turns out”

“Command two” should be “Command 2”.

“at both sides of the equals sign” ==> “on both sides of the equal sign”

“match out the first name of the person” sounds weird; I’d just say “match the first name of the person”.

Also, make sure you mention that “_” can match different things; it isn’t a variable as such.

Bottom: It might be nice to mention that the evaluation rule in Erlang evaluates element of a list before constructing the list.

Top: We don’t have to “chop off” the head of the list to have the tail of the list. The tail is simply everything except for the head.

Also, the statement “the tail of a list is always a list” is technically true, but it’s misleading since you can have improper lists where the tail isn’t a list. Footnote?

The $ is basically a unary prefix operator converting character atoms to numbers. Maybe this should be mentioned.

(Joe says: It’s Not actually a unary operator-it’s syntax)

Under the subheading “Syntax:” you say,

“If L is a list then [X|L] is also a list, with head X and tail L.”

The use of [X|L] is unfortunate since if you try something like:

L = [1, 2, 3, 4].
[X|L] = L.

It won’t match. You should problably write something like.
“If L is a list then [H|T] is also a list, with head H and tail T.”

The beautiful little perms/1 program does have a flaw in that it returns duplicates if the input list contains duplicates. If you’re not going to explain the program, perhaps you should at least mention this.

perms(L) -> lists:usort(perms1(L)).
perms1([]) -> [[]];
perms1(L) -> [[H|T] || H <- L, T <- perms1(L — [H])].

(Joe says: I’d rather not explain this)

Trying to enter the definition of for:

Erlang (BEAM) emulator version 5.5.2 [source] [async-threads:0] [kernel-poll:false]

Eshell V5.5.2 (abort with ^G)
1> for(Max,Max,F) -> [F (Max)];
1> for(I,Max,F) -> [F (I)|for(I+1,Max,F)].

1: syntax error before: ‘->’
1>

(Joe says: Not an error - this is what must be in the file. you can’t type this into the shell.)

The intro to “Case and if statements” says that pattern matching is sometimes inconvenient. But case and if statements are based on pattern matching every bit as much as pattern matching in the function head. It should really say that defining separate function clauses for everything is inconvenient.

“Sometime a receive statement might…” May be what was intended but if so it sounds a little awkward.

misspelling of timeout as timout in the infinity paragraph

misspelling in first paragraph: accoriding

I like to see the problems at the end of this chapter. It’d be nice to see some problems or excercises in earlier chapters too.

Maybe it is interesting as an anecdote to point in the introduction to Intel’s Teraflops Research Chip. This chip contains 80 cores and is claimed to be very energy efficient. So, another reason for choosing Erlang would be that you can take full advantage of such a chip in the future which would mean energy savings and less cooling needed in data centers…also 2 hot topics these days.

Some links about this chip:
www.eetasia.com/ART_8800453831_1034362_db7dce9c200702.HTM
www.intel.com/research/platform/terascale/teraflops.htm

(Joe says: will be address in introduction chapter (not yet written))

The last bullet point on the page: “nil is the last argumnet in the connect call.”

The second paragraph: "…but MSDs are very useful for viualising what

“The function connect/5 simple creates a parallel process by
spawning handler/5.”

I think “simple” should be “simply”.

In the third paragraph, which is after the first code example: “When a connection message arrives (which will occur in the disconnected state) the client sends a login message to the sever and waits for the reply in wait_login_response/2.”

After the code example, the first sentence: “The sever loop is simple.”.

In the first numbered item on the page (“2.”), the text starting “(for bases greater…” does not close the parentheses properly. As a suggestion, make that text a new sentence without the parenthesis: “For bases greater…”

In the second paragraph:
Since the tuple itself is just contains…

Should be:
Since the tuple itself just contains…

“The connected process has a special signifance: all message to the external program must … ”

“message” should be “messages”

Section 4.1 on stopping the shell.

what about
1> q().

Two places on this page, there are dollar signs (command line prompts) before the first Unix command, but not before the second one. For example (don’t know if the formatting will be screwed up here):

$ chmod u+x hello.sh
./hello.sh

should be

$ chmod u+x hello.sh
$ ./hello.sh

In the sction “Run as an Escript” in the paragraph starting “On a Unix system…”, “We” should be uncapitalized.

In the paragraph “Creating Tuples”:
5> [true, Q, 23, Costs].

But lists haven’t been introduced yet, so it should be:
5> {true, Q, 23, Costs}.

In the first paragraph on the page, there is a period (full stop) missing after “Hello world had no arguments”

The last paragraph before Erl Interface is described: “There are however, a number of libraries included in the Erlang distribution which simplify the job of interfaceing Erlang …”

The first code example in “1.9 Tweaking the Environment” starts with the line “help().” twice. Only one is necessary.

“functiions” should be “functions”

“In general lists should always be built by appending elements to the start of an existing list [. . .]”.

The correct term here is “prepending”, not appending, since we are adding elements to the front of the list.

In the explanation of list_bo_binary BIF, “Here IoList is a list, who elements” should read “Here IoList is a list, whose elements”

Minor point: I’d consider changing the word “objects” in the sentence “because the shell objects like crazy and says:” to “complains” or something similar. Only because seeing “shell objects” together makes me think of some OOP construct and then I’m looking for the verb in the sentence… I had to read the sentence twice to figure it out.

The processes:max() function prints the value of

erlang:system_info(process_limit).

Perhaps add a remark that some of these processes are reserved for system use, and so only some lesser number can be started in this test.

The elements in Result are in the opposite order to the elements in the
origonal list,
——

should read “the original list”

“But nothing could be further from the true”. Should be “truth”.

Minor point: If you’re going to use the Queen’s English with “learnt” instead of “learned”, then “eyecolor” (pg. 23) should be “eyecolour”. 8^)

“brackets” is used instead of “parentheses” throughout this page.

Last bullet point (“Miscellaneous topics”). One “topics” to much in the sentence.

In the “TypeExpression” second item (“2.”). “the list {X1,X2,…,Xn}” should that use “[]” instead of “{}”?

I find the talk about the Erlang Type Notatio rather incomprehensible. At first I didn’t even understand that this is just for documentation and not part of the language. I guess it should be clearly explained what it’s used for.

(Joe says: this will be moved into a new chapter)

so we

3.3 Error handling, Exception, the paragraph starts with “We don’t try”. “as no possible repair is possible” does not sound right.

I find the overuse use of the phrase “crash” in section 3.3 sounds peculiar and, to me, was unhelpful. As a motto it’s fine but otherwise I would suggest using exception terminology earlier.

(Joe says: My programs crash - I don’t want to alienate people
by using a too strict language at a point in the text where
it’s not necessary. I’ll be much more precise in the
error handling chapters. This is after all, only an introduction.)

Booleans: There are no booleans in Erlang only the atoms true and false.
——

The very next section goes on to talk about boolean expressions and how “not true” is false. If ‘true’ and ‘false’ are just atoms then surely ‘not true’ should have as much meaning as ‘not ham’?

Section 6.2: (A) The title should be “An on_exit Handler”, not “A on_exit Handler”. (B) In the first paragraph, the second sentence should be “We can write…”, not “We can wrote…”

I went ahead and created a lists.erl file and defined sum and map. When I tried to compile the module, I get the error below. I realize the problem now, but you might point out to the reader not to try to redefine “system” modules and what “sticky” is.

3> c(lists).

=ERROR REPORT 5-Mar-2007::19:09:10 ===
Can’t load module that resides in sticky dir
{error,sticky_directory}

(Joe says: dded a new sidebar called
I like this draws attention to this but doesn’t break the flow)

It might be worth introducing “=:=” in the text as I think this is the first time we’ve come across it.

2nd line, the io:format argument “off we co …~p”

2nd last paragraph of subsection 8.5: “creates four windows all of wich connect to”

Description of example1_driver.c: “and calls the rotuines in example1.c”

“that creates a link to the the process”

capitalized Else isn’t consistent (of course it is pseudocode)

“non /normal/” should probably be “/non-normal/” or at least “non-/normal/”

I don’t think race condition requires a hyphen.

but I think the adjective in “single-processor systems” does require a hyphen.

I see the erl_crash.dump file mentioned in some makefiles, as clean target. It would be nice to know how to use them for debugging.

Building Erlang from Source

There is an Erlang port in the FreeBSD ports collection.

Just do the usual make install dance and the port will automatically fetch the distfiles, check, extract, patch, configure, build and install it.
Example (the distfiles are already in ports/distfiles):

[root@hokage /usr]# cd ports/lang/erlang
[root@hokage /usr/ports/lang/erlang]# make install
=> Extracting for erlang-r11b3_3,1 => MD5 Checksum OK for erlang/otp_src_R11B-3.tar.gz. => SHA256 Checksum OK for erlang/otp_src_R11B-3.tar.gz. => MD5 Checksum OK for erlang/otp_doc_man_R11B-3.tar.gz. => SHA256 Checksum OK for erlang/otp_doc_man_R11B-3.tar.gz. => MD5 Checksum OK for erlang/otp_doc_html_R11B-3.tar.gz. => SHA256 Checksum OK for erlang/otp_doc_html_R11B-3.tar.gz. => erlang-r11b3_3,1 depends on file: /usr/local/bin/perl5.8.8 - found
=> Patching for erlang-r11b3_3,1 => erlang-r11b3_3,1 depends on file: /usr/local/bin/perl5.8.8 - found
=> Applying FreeBSD patches for erlang-r11b3_3,1 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- configure.orig Fri Dec 7 16:13:39 2001 |+++ configure Fri Dec 7 16:19:33 2001 -------------------------- Patching file configure using Plan A... Hunk #1 succeeded at 1224 (offset 143 lines). done => erlang-r11b3_3,1 depends on file: /usr/local/diablo-jdk1.5.0/bin/java - found
=> erlang-r11b3_3,1 depends on executable in : gmake - found => erlang-r11b3_3,1 depends on file: /usr/local/bin/perl5.8.8 - found
=> erlang-r11b3_3,1 depends on shared library: iodbc.3 - found => Configuring for erlang-r11b3_3,1
creating cache ./config.cache
Disabeling caching
Removing cache file ./config.cache
checking host system type… i386-unknown-freebsd6.1
checking for GNU make… yes (gmake)
checking for a BSD compatible install… /usr/bin/install -c -o root -g wheel
checking whether ln -s works… yes
checking for ranlib… ranlib
updating cache /dev/null
creating ./config.status
creating Makefile
configuring in lib
running /bin/sh /usr/ports/lang/erlang/work/otp_src_R11B-3/lib/configure —enable-threads —enable-hipe —prefix=/usr/local —cache-file=/dev/null —srcdir=/usr/ports/lang/erlang/work/otp_src_R11B-3/lib
creating ./config.status

etc.

I expected some mention of concurrency, mutation, locking, etc. here - even just a pointer to a longer discussion later in the book.

(Joe: will be included in new chapter or appendix)

In the section on FP perhaps mention how to do integer division?

“In Erlang variables, variables are just like they are in math.” - remove first “variables”

I’m not too happy with equating atoms and C enums or #defines - C programmers very frequently depend on the numerical properties of the enum symbols. You should make it clear that atoms don’t have a numerical value.

birthday(X#person{age=N}) ->
is syntactically invalid.
birthday(#person{age=N} = X) ->
would work.

Since erlc understands .yrl files, there is no need to have a separate makefile rule for them.

The parser definition files have the extension .yrl, not .yecc

“The client and server in a client-server architecture are separated processes” - should be “separate”

"These bindings are made

In the 1st paragraph of 6.2, “We can wrote a function […]” should read “We can write a function […]”

The described ways to run a program rely on the fact that a module has some function that either has 0 args, or accepts args as a list of literal strings. Frequently one wants to be able to execute an arbitrary Erlang function from OS command line. I suggest mentioning the -eval argument that is very handy for quick scripting:

erl -eval ‘io:format(“Memory: ~p~n”, [erlang:memory(total)]).’ -noshell -s init stop

—Serge

“I’ll only show the banner (…) this information is only useful” is not grammatically correct.

“Let’s see how in the next chapter….” should have only 3 dots

(Dave says: actually, 4 is correct: three for the ellipsis and one for the end of sentence)

This is the meaning of the {packet, N} argument in the gen_tcp:connect
and gen_tcp:_listen functions.

Should be gen_tcp:listen

In the 11.2 “Control issues” section the opening sentence says that sockets can be opened in one of two modes (active / passive), yet the following paragraphs talk about three modes {active, true | false | once}.

Additionally, the sentence “If the socket was opened in passive mode then the controlling
process is only sent one message each time it calls the routine
gen_tcp:recv.” is inaccurate. In passive mode the controlling process doesn’t get one message - it uses the gen_tcp:recv call to fetch N bytes from the socket descriptor.

It may be worth noting that if hosts running UDP listeners are in different network subnets, the UDP broadcasts likely won’t reach them, as by default routers drop such UDP broadcast packets.

“The infix operator X—Y is a copy of the list X where any element of X which also occurs in Y have been removed.”

that sounded to me like “[1,1,1,2]—[1]” should result in “[2]” while it actually results in “[1,1,2]”

The code tar contains no hello.beam and hello.sh exposes Joe’s work directory path.

(Joe says: ello.beam is created when you run make
add note about the absolute path)

At bottom of page, “are not know in advance” should be “are not known in advance”.

First line on page: “.erl Modules must be…”
There should be a full stop after .erl, since it ends the sentence it belongs to.

Line above “Extending the Program”: “Width*Ht ie 10*5 = 50.”
should be “Width*Ht, i.e., 10*5 = 50”, otherwise the “ie”
looks like some kind of operator.

Last par.: “In this case, the order of the clauses doesn’t matter, the program means the same thing no matter how the clauses are ordered.”
A newbie probably asks “why is that?” here. You could make it clearer by pointing out that the clauses, as written, are mutually exclusive - no single term can match more than one.
Oh, and substitute a semicolon for the comma after “matter”!

Figure 3.2 “Term comparisons” is missing the “>” “greater than” operator.

Second bullet point: “We do not say what will happen if none
of the patterns match, we merely fail with a badmatch error.
This is deliberate.”
The use of “we” here is confusing. Rephrase as “The function
does not say what to do if none of the patterns match the
actual arguments. This is deliberate. If it should happen,
the function call will fail with a badmatch error.”

Second bullet point: actually, it won’t be a “badmatch” error, but a “function_clause” error. Perhaps better to just say that there will be a runtime error (no emphasis on runtime).

In the section where Double is created and assigned, the line containing “4> Double(4)” is missing a period at the end of the statement.

Last par.: “In line 1 we compile …”
This paragraph ought to be moved to page 32, before the paragraph “So what happened here” but after the example (and be rewritten to match the “math4” example).
In addition, you should add a few words about the syntax “math4:area(…)” for calling functions in modules.

The grey box with the “Tip” talks about writing export declarations - but you still haven’t described those at this point in the book! A good place to do so would be on page 35, just after the code for the “shop” module, explaining briefly that the function cost/1 must be declared as exported in order to be used outside the module. You should also explain the -module(…) declaration, at that point or perhaps even earlier.
Furthermore, in the grey box, don’t say “The compiler option …”, but “The special declaration …”, and make sure there is a period after the closing parenthesis!

In fact, the grey box with the tip about “-compile(export_all).” comes much too early in the book, and would be better in chapter 4, “Compiling and Running your Program”.

Second par.: “…and the system printed out an error message”.
This would be a good place to briefly explain that “function_clause” in an error message means that a function call failed because no clause matched the arguments.

Last par.: “…it removes the head from the list,…”
It’s best to avoid wordings that sound like you are modifying the data structure. Rephrase as “…it picks out the head and the tail of the list,…”

Par. 5, “…, so far the code…”
This should be the start of a new sentence, or at least the comma should be replaced by a semicolon.

Par. 5, “they breath fire” should be “they breathe fire”.

Par. 1, “And use it…”
This is not a new sentence, and should begin with “and” in lower-case.

In the equivalent c-code for the function matching example:

"
area(struct Shape* s) {
if( s->kind = Rectangle){
int width, ht;
width = s -> shapeData.rectangleData.width;
ht = s -> shapeData.rectangleData.ht;
} else if (s->kind == Circle){ …
"

First, in your first “if” check, you’re assigning the value Rectangle to s->kind rather than testing the value, and secondly, this really would be written as a switch. There’s no sense making C look uglier than it has to.

Par. 4, “The code inside the brackets”.
Please make it clear that the parentheses (not “brackets”!) are there for pedagogical reasons, to mark the “body” of the fun, and are not strictly necessary.

(Joe says: there are nearby examples without the
additional parentheses - so this should be clear
adding an additional comment would be even more confusing)

Grey box, par. 1, “In practise” should be “in practice”.
Also, last bullet point: “functions with return funs” should be “functions that return funs”.

Section 2.4: avoid giving the impression that the reader should try to define his own lists.erl module and compile it. In particular, move the footnote (about omitting the commands for compiling the module) to some earlier example where it actually applies. Make it clear that you are showing the definitions of the functions that already exist in the standard library “lists” module.

Sec. 5, “Now that we’ve defined”. Rephrase as “Now that we know about”, to avoid giving the impression that the reader should create his own versions of these functions.

Last par.: “-import(lists, (…)).” should be “-import(lists, […]).” with angular brackets instead of the inner parentheses.

Bullet point: You ought already to have described -export declarations previously in the book (soon after -module declarations), so you should only describe -import here. Anyway, “-export((…)).” should be “-export([…]).” with angular brackets instead of the inner parentheses.

First sentence “d(dog)”. You either mean “g(dog)” or “h(dog)”.

Are there any examples on the bit synatx following somewhere in the book? I don’t think it’s really understandable as is.

(Joe says: there are already many examples of bit syntax)

Maybe you should try to explain (at least) the first example. I mean, there are some functions used that are unknown to the reader and it’s also not entirely clear how the bit syntax works (e.g. what up with the “#”).

“To write an write my Erlang program I first defined four macros.”

the second entry in the example:

2> Y = 10

is missing a period at the end.

In the “get_word” function you’re using the comma. And I think this is the first time this is used and unfortunately not explained.

(Joe says: these are defined earlier)

“…so we often see programs which manipulated tuples…”

Should be manipulate tuples (without the d) so that tenses agree.

A concrete example of a record would be nice. Just typing the given -record(person, …) into erl gives a badmatch error, and it doesn’t work in a file either (as far as I can tell).

Section 5.2, bottom of the page, Paragraph started with “Note Pid !”: s/Pid! !/Pid1 !/ . -Brian Zhou

(Dave says: I believe it is correct as it stands)

In the subsection Reading ID3 Tags, first paragraph, “MP3 files do not themselves contain information about the content of the file, so, for example, in an MP3 file contains music …”

It sounds like it should be “in an MP3 file that contains music”

Second paragraph from bottom: “windows machine it will write carriage-return line-feed ASCII (13, 10)” I think the “w” should be capitalized.

The last paragraph before the bottom example: “(ie it only output the characters embedded in the lists and not the list brackets themselves).”

Section 5.7, first paragraph, 3rd line
s/One the other hand/On the other hand/

First paragraph under the sample: “{packet,0} means that the TCP data is is ‘unframed’”

Section 6.2, 2nd sentence —- “We can wrote …”
Wrong tense. It should be “We can write …”

Fourth paragraph from the top: “Most packet sniffers include software which can decode and analyze the data in the packets and present the data in a meaningfull manner.”

Last paragraph: “acts as aport interface”

First paragraph: overwriting the origonal content

Note 1, 2nd line: gen_tcp_connect should be gen_tcp:connect

“The next sections show how to compile and run a couiple of programs…”

couiple should read couple.

“In the next chapter we’ll start looking at concurrent programs”. It seems that the chapter about compiling and running programs has been inserted before the chapter about concurrent programming.

Duplicated command:
1> help().
2> help().

On Windows, the environment variables HOMEDRIVE and HOMEPATH point out where to look for the .erlang file, not HOME.

Erlang actually uses the following command

init:get_argument(home)

to find out where Erlang will look for the .erlang file.

There is also an -eval option. If you also export fac/1 from the fac1 module, the following will work:

erl -noshell -eval ‘io:format(“~p\
”, [fac1:fac(25)]), c:q()’

Relatively minor, but I think

$ chmod u+x hello.erl
./hello
Hello world
$

should probably read
$ chmod u+x hello.erl
$ ./hello.erl
Hello world
$

Repeated ‘and’

two things, types and and function specifications.

Include file in C is named “glob.hrl” instead of “glob.h” at the bottom of the page.

last para: repetition of ‘the’: pattern matched against the the calling arguments

“A B add (ie appends) …”. That should be add*s*

So what’s the difference between == and =:=? I mean how should I interpret the difference between equal and identical. You hit that it has something to do with floats but it’s not actually explained.

(Joe says: it’s explained under terms, earlier)

In Figure 2.1, argument type is “number” or “integer” but in the main text (first par of section 2.6), it is referenced as “integer” or “mixed”. So there’s a mismatch between “number” and “mixed”.

“Sometime a receive statment might…”

Statment should be statement, and Sometime should probably be sometimes.

In the Code section there is a duplicate/1 function that uses lists:member/2. I think this code may be re-written to avoid this call:

duplicates2(X) -> find_duplicates2(sort(X), []).

find_duplicates2([], L) -> L;
find_duplicates2([H,H|T], [H|L]) -> find_duplicates2(T, L);
find_duplicates2([H,H|T], L) -> find_duplicates2(T, [H|L]);
find_duplicates2([_|T], L) -> find_duplicates2(T, L).

All the best,
Philip

(PS: Sorry about entering page number 0 - I saw this on the “Code” link on the website so I don’t know where it is in the book.)

In the section 2.8, first paragraph means essentially the same as the third paragraph. Maybe this redondancy could be avoided.

“When we program with tuples, we can run into a problem when the number of elements in a tuple becomes large. It becomes difficult to remember which element in the tuple means what. Records provide a method for associating a name with a articular element in a tuple, which solves this problem.”

=

“As the number of elements in a tuple becomes greater it becomes more and more difficult to keep track of the meanings of the individual elements in the tuple. When the number of elements in the tuple is large, or if we wish to name the elements in the tuple for documentation purposes, then we can use records instead of tuples.”

It is unclear to me why we need to write X two times in the pattern matching clause of the function.
birthday(X#person{age=N} = X) -> X#person{age=N+1}.

In fact, i’m asking why the first X should be there. Why not write:
birthday(#person{age=N} = X) -> X#person{age=N+1}.

I guess this has to do with syntax. It might be interesting to clarify that.

Another thing, I was not able to run the example. I tried writing the record definition in the shell or in a module but without success. It looks like the export clause in the module should be different from what is used for exporting functions.

(Joe says: it was a bug)

In discussion of the Erlang exception handling, I’d suggest covering the try-catch mechanism too. The original catch expression is ambiguous in some cases. I remember that from a paper written by Richard Carlsson.

(Joe says: Try-catch is in the pipeline - it will not be forgotten :-)

In the list of type notations, “tuple() is an tuple.”

in my erlang shell (5.5.2) ‘record’ raises a badmatch error. If I use ‘rd’ the examples work.

Under the subheading “Syntax:”,

“If T is a list then [H|T] is also a list, with head H and tail T.”

That should probably be “If L is a list the [H|T] …” since [H|T] = T won’t match.

(Joe says: the original is correct)

Under 1.
The pdf says “Is ou instead have spaces there…” when it should probably say “If you instead have spaces there…”

What is OTP? I’m familiar with Online Transaction Processing, but I do not believe that is the use here. Perhaps at least a mention of what OTP stands for.

(Joe says: will discuss in introduction (not yet written))

Bullet item 3 mentions make and Makefiles which are very familiar to C/C programmers in Unix. Do you want to mention other build tools such as ant which are more familiar to Java programmers?

(Joe says: there are many build tools I won’t mention them all
only make)

Bullet 4 mentions the library collection named OTP. I’m only familiar with this acronym standing for Online Transaction Processing. What does OTP stand for?

(Joe says: will be discussed in the introduction)

When I first read the last paragraph on page 8 and the first paragraph on page 9, I thought, “Have I mixed up my pages? Something is missing.” The transition from “…a working knowledge of the language.” (p.8) to “Now that you’re comfortable with Erlang….” (p. 9) seems harsh.

At the top of the page, should be “output” not “oputput”

The first paragraph mentions the term ‘cluster’; however, you do not define this term.

In paragraph 1, you mention ssh. Most Unix programmers will be familiar with this shell; however, most Windows programmers will not.

“…variables start with upper-case letters).” I thought that the closing period went inside the parentheses when the text inside was a complete paragraph. (It’s been a long time since I consulted a style guide.)

“…single assignment variables can only be given a value once.” I was unclear if this statement indicated a global scope or if binding occurred locally. For example, can I bind the variable X to one value in one function but to another value in another function?

Third paragraph, s/are some are some/are some/

Last line on the page, s/have a have a/have a/

Section “Variables that Don’t Vary.” This section distinguishes between binding and assignment. For programmers not familiar with Prolog, do we want to explain the difference between these two terms “up front” since we explain that variables are “single assignment variables” but are “bound” and not assigned?

Last line in paragraph starts with “Distributed Erlang applications run …”, s/a open network/an open network/

Last line in paragraph started with “We are all used to”, s/Even thought/Even though/

BIF description for disconnect_node/1, tense problem
s/Forcibly disconnected/Forcibly disconnects/

Although this test may work on Unix systems, it does not work on Windows (unless the reader has changed the PATH variable). Windows programmers (on XP) invoke Start > Control Panel > Add or Remove Programs. When the applet opens, search for “Erlang OTP R11B” (depending on installed versions).

)Joe says: added comment and reference
to section that I’ll write about windows)

Invoking the command erl in a Windows cmd window only works if the reader has installed Erlang and changed the PATH environment variable to refer to the program. Assuming the reader installed the program in the standard way, the reader must invoke Start > All Programs > Erlang OTP to run these commands.

)Joe says: added comment and reference
to section that I’ll write about windows)

The section labelled “1” does a great job describing how things work on Unix. What about describing how things work on Windows?

)Joe says: added comment and reference
to section that I’ll write about windows)

Box. Although this procedure may work under Unix, the Erlang window under Windows does not seem to respond to Ctrl-C (other than to reprint the command number). (I tried simply pressing Ctrl-C after first opening the Erlang window.)

Sidebar. In Windows, one types Ctrl-Break to get the “BREAK” message.

“…different non-numerical atomic values.” I find it confusing to define atoms in terms of atomic values. (My experience as that the phrase “atomic” is used in the context of database transactions or concurrent updates.) Perhaps by “atomic” you mean “a object whose value is itself” (although I’m not certain if that phrase accurately communicates what you want to say).

“…atoms are global in scope….” When I read that, I understood it to mean that all modules share a single, global name space; i. e., X defined once precludes all subsequent uses of X. I believe atoms are global in some scope: a module or a function. If we do not want to get into the details of scopes, we may want to refer to a future discussion. Otherwise, we might want to mention scopes.

“…you might want to create a tuple{”joe“, 1.82}”

Missing a period.

Context: …a tuple {“joe”, 1.82}. On page 22, we mentioned atoms and using single quotes to create atoms containing “unusual” characters. On page 23, we then suddenly use double quotes. When I first read this phrase, I thought joe was intended to be an atom. If it is an atom, I suggest using single quotes (or nothing); otherwise, I suggest mentioning double-quoted strings.

Context: “struct point…P” I believe the statement in C requires a semicolon (but its been a long time since I’ve written C).

“…and stores it in the variable P.” This statement sounds like an assignment in other languages. Do we want to communicate this idea to the reader?

“Sometimes programming with links is tricky, because links are symmetic.”

symmetic should be symmetric.

“The first two bytes, encode the packet length, this is followed by the result 77 (again one byte long).”

Should read:

“The first two bytes encode the packet length. These are followed by the result 77 (again one byte long).”

The text uses the phrase ‘“in parallel.”’ Because of the double quotes, I was unclear if this phrase actually describes the details or if we might need a reference to a later description.

The sixth paragraph uses the phrase “same shape.” I do not believe we have mentioned the word shape before. Do we need to provide an explanation of this term?

Section 1.10 describes lists; however, it fails to mention the empty list. Do we need to mention this special list?

At the bottom of the page: “To be really sure we look for three consequtive headers.”

The second paragraph of section 1.12 mentions the word “terms.” I believe this instance is the first mention of this term. Do we need to define this word before using it?

The code example in the middle of the page uses the expression “f().” The next to the last paragraph on the page describes the forget function. When I first read the code text, I wondered if I had missed or forgotten a previous description of the function f(). Might putting the description of f() before the code block make the code more understandable?

There are two typos of the word consequtive. At the bottom of the page, point 2 in the list and the next to last sentence of the page.

“find_sync tries to find three consequtive MPEG header frames.”

First paragraph of “Functions Which Have Funs as Their Arguments” states “The module lists exports several functions…” and then shows an example of using lists:map(). Make it clear that lists:map() is not defined yet and will be built as part of the test. It looks like it’s part of the standard library and I spent several minutes figuring out what I was doing wrong. ;)

“You’ll see how the ideas on pattern matching, that we learnt about in the first chapter, are used when we define functions.”

First paragraph. I do not believe that the two commas in the last sentence of the first paragraph are needed.

“…with the final program and no explanation….” I believe the “with” better expresses the idea than “and.”

“In lines 1 to 4…in lines 5 to 14….” I think that using the shell input numbers is clearer than the actual line numbers.

“…have moved ‘inside’ the modules…” Since the text has already talked about binding, I believe it is clearer to continue using this terminology. When I first read the term “moved ‘inside,’” I wondered if some kind of copying was occurring.

I found describing area as having “several different entry points” confusing. The phrase “entry points” reminded me of Windows DLLs in which callers decide which entry point to call. In this situation, it seems as though the entry point is the first clause of area and the function has a set of branches taken based on the matched clause.

“enum ShapeType…” might be preferable to “enum ShapeSort.” When I first read this name, I wondered “Are we going to sort the shapes?”

“if( s->kind == Rectangle){” seems to be missing a space between ‘)’ and ‘{’.

The expressions “s -> shapeData…” should be “s->shapeData…” to be consistent with other formatting.

The code fragment “(s->kind == Circle){” is missing a space between ‘)’ and ‘{’.

In the last bullet item, the text says that object-oriented languages put data and their functions in the same place. Proponents of object-oriented programs might argue this “requirement” is a strength. Might a sidebar explaining the advantages of putting these items in separate locations be worthwhile?

(Joe says: his is a long and complex argument - I can’t do justise to this
in a sidebar - this needs an entire book)

The phrase “…data structures that create and manipulate instances of circles….” might be better expressed as “data structures that represent and functions that create and manipulate instances of circles….”

The author briefly describes how people organize object-oriented code (“…data structures that create…located in the same place”). Might a sidebar describing how to organize code in Erlang be appropriate?

The text says “Each clause contains a pattern…” Earlier, the text described that a clause consists of a head and a body. Might the text be clearer using a phrase like “The head of each clause contains a pattern…”?

The third paragraph uses the phrase “…pattern which is just an atom.” Perhaps it is my “Prolog showing,” but I understood the head to contain two atoms cost and, for example, apples. Perhaps the meaning would be clearer if the text mentioned both the function name and the atom?

The list “…[{oranges,4},{newspaper,1},….” might be more consistent with other entered lists with whitespace. For example, “…[{oranges, 4}, {newspaper, 1},….”

Tip box. Although the approach mentioned (write a bit and then test a bit) works especially in a shell environment, I wonder if a mention of any unit testing frameworks - or lack thereof - might be appropriate at this time.

“…actually did two different things, firstly it looked….” I believe this text should be two different sentences: “…actually did two different things. First, it looked….”

The text asks the reader to enter the text “Double = fun(X) -> 2 * X end.” Might entering the text “Double = Z.” help to reinforce the ideas of binding discussed earlier?

“Among other things this means that funs can be used as the arguments to functions….” Is this characteristic a characteristic of functional languages or any language that treats functions as first class objects (Scheme, Python, and so on)?

(Dave says: probably a diversion here…)

I believe the phrase “…programming languages, they breathe fire….” should be “…programming languages: they breathe a fire….” (or perhaps a dash).

I believe it may be worthwhile to add a sidebar comparing funs returning funs with closures.

(Dave says: this will probably disrupt the flow)

I definitely think a chapter on the available tools for working with Erlang ( like all of the beautiful emacs stuff that is included in the distro ) would be good.

Emacs, Eclipse and those kinds of things. ( Debugging, Monitoring, Profiling, etc ).

(Joe: will be included in new chapter or appendix)

The name “math4” for the module is not very suggestive. I recognize that “math” is taken. Maybe a name like “geometry” would be better.

The sentence: “This makes
writing and extending programs very easy, we just add more patterns.” is grammatically incorrect (comma splice). Change the comma to a semicolon.

The sentence “We do not say what will happen if none of the patterns match, we merely fail with a runtime error.” is grammatically incorrect (comma splice). Replace the comma with a semicolon. I’m guessing there will be a lot more of these, so I won’t submit any more errata of this form.

In the sentence “Since Erlang is not an Object Oriented language, …” there is no need to capitalize “Object Oriented”, though you might want to hyphenate it (“object-oriented”). More significantly, although the example makes a good point, it overlooks the fact that to add extra clauses to the area function you need to rewrite and recompile the module, whereas in Java you just define a new class and compile it (but the old code stands as is). This is a classic tradeoff between an OO approach and a functional approach. I’m not sure if this needs to be mentioned, but don’t convey the impression that the Erlang approach is inherently superior in all ways; it’s just much lighter-weight.

The phrase “provide the interfaces to the exported
functions remain the same” should be “provided the interfaces to the exported functions remain the same.” Also, you might mention that the -compile lines come at the top of the file, right under the module lines (do they have to?), and that lines starting with have special meanings to the compiler.

In the explanation of “shop1:total([{milk,3}])”, you say that T matches the empty list. This is true, but why it’s true may not be evident to programmers who haven’t studied functional languages.

At the bottom, make sure you mention that “(do something with the variables in Head)” is pseudocode.

The statement “funs can return funs” suggests that only anonymous functions can return funs. You should say something like “funs or ordinary functions can return funs”.

The word “learnt” is not idiomatic American english. We write it “learned”.

For the Even example, is it necessary to use bitwise and? Surely Erlang has a modulus function.

“Writing functions with return funs” should be “Writing functions which return funs”.

The description of the “for” function at the bottom of the page is nice but somewhat misleading. In imperative languages, “for” works by side-effect and doesn’t return anything. Your version is an enhanced “for” control structure, since it returns a value. Footnote?

“at same time making them a lot clearer” should be “at the same time making them a lot clearer”.

"Here

"Later, we

After the code fragment “[{A,B} || {A,B} <- Buy].” you state “This is almost what we want but not quite.” That’s silly; it’s just a copy of the list. Just drop this sentence. Then in the line "we

The statement “X#person{age=K} makes a copy of X replacing the old value of the field named age in X with the value K.” could be misinterpreted as referring to the left-hand side of the -> operator (i.e. the pattern match). This needs to be clarified.

The statement “If you ever see code like this:
List [H]
It should set alarm bells off in your brain” is correct, but readers will wonder why you used the operator in the quicksort function. You should clarify this.

“We don’t need any control structures.” Is this actually correct or is more accurate to state “We don’t need additional control structures.” In addition, I’m wondering if this statement is provable. I believe, for example, that it was proved mathematically that a language did not need a go-to statement. If this statement is empirical, we may want to qualify it to avoid the broader import.

“…at the same time making them a lot clearer.”“” Although I agree that higher order structures are more lead to dramatically more powerful programs, I’ve also found that these are sometimes more difficult to understand at execution time and are sometimes more difficult for readers less familiar with these constructs. Do you want to address this issue?

“The function pyth(N) generates…” should be “The function pythag(N) generates…” to be consistent with the code block in the middle of the page.

“…(ie something like….” should be “…(i. e., something like….”.

On pages 50 - 53, the text refers to “guard predicates”, “guard term comparisons” and “guard built in functions.” When I read these pages, I wondered if these particular expressions were only valid in guards. However, on page 53, the text states “…a guard can be used as an expression…” How can the text clarify whether the predicates and expressions used for guards are unique to guard clauses or are general expressions in the language?

“Finally, a guard can be used as an expression, it will….” I believe this fragment should be two sentences: “Finally, a guard can be used as an expression. It will….”

Figure 2.4 describes the function “element(X, N)” When I attempted to invoke this function in the shell, the shell responded with error messages. When I tried executing “element(1, {1, 2, 3, 4})”, the shell responded as I expected.

Last sentence: “This returns the IP address and Port of the other end of the connection, so the server can who iniciated the connection.”

Second paragraph in section 11.5: “UDP is a so-called connection-less protocol, which means that the client does not have to establish a connection to the sever”

Second paragraph in section 11.5: “This means that UDP is well suited for applicatations where large numbers of clients send small packets to a server.”

Last sentence before example: “The code for a remote proceedure call now looks like this:”

Last sentence: "If you look at the real code, you

I am still confused by the meaning of the Boolean sections.

First it states that there are no booleans. Then it explains how the atoms ‘true’ and ‘false’ are interpreted as logical values, how they interact in boolean expressions, and how things evaluate to booleans.

If the point is that there in no distinct type called ‘boolean’ then I think that it would help to say “There is no distinct boolean type in Erlang instead the atoms ‘true’ and ‘false’ are given a special interpretation.”

If it’s not down to type then I just don’t understand…

At the bottom of the page: Don’t you mean “edemo1:start(false,normal).” instead of {die,normal}. Or is “exit(normal)” the same as just finishing the function normally?

“This program is identical to edemo1 with one small change to the function c/2 to make it call exit/2.”

Well, I wouldn’t say that c/2 is nearly identical to the old one. It’s a completely different function!

Section 2.3 defines “arity”, but at the bottom of section 2.4 the “terminology” paragraph redefines it.

“If X occurs in many differnt functions then all the values of X are differnt.” - shouldn’t this be 2 times different instead of differnt?

The code fragments on this page can neither be entered into the Erlang shell nor compiled from an external file.

When I tried entering the record definition, the shell responded with an error message.

When I entered the 3 code blocks in an external file, I encountered several errors. The phrase ‘X#person’ appeared to be illegal. Removing them, the compiler then complained about X being unused. Replacing X#person with #person allowed the code to compile.

After compiling the record definition and the function definition, I tried to bind Person to a new record. The shell complained about the symbol #person being undefined. Even after adding the module qualifier record_eg (record_eg:#person, record_eg:person, record_eg#person), the shell complained about syntax errors and about record person being undefined.

(I’m just barely familiar with Erlang. It could well be user error.)

I believe that “…case is evaluated as follows: Firstly….” should be “…case is evaluated as follows: firstly….”

I do not understand the intent of the footnote “8. lists:reverse is recognized by the compiler and replace by efficient code to reverse the list.”

If the reader is entering the suggested code fragments herself, he code fragment “{reverse(Odds), reverse(Events)}.” fails to compile. To compile it, the reader must include the fragment “-import(lists).” or change the reference to “lists:reverse.” (Although the author mentioned earlier that he would no longer include the “standard ‘prologue,’” I do not remember if this included the import statement.)

The last paragraph states “The next chapter covers all the remaining details…”; however, the next chapter is named “Advanced Sequential Programming.” When I read a chapter title containing the word “advanced,” I assume that its not necessary; however, the statement about the remaining details tells me it is necessary.

How can the text better communicate the relationship between chapters 2 and 3?

Two suggestions:
First, I would like some info about available tools: What are good editors on Linux, Windows and Mac OSX? What do people use? How about profilers, debuggers and the like?
Are there existing config files for emacs, Eclipse or other editors, at least enough to get paranthesis/bracket matching and perhaps syntax highlighting?

Second, I would like at least a brief description of style issues (as Erlang has been used in industry for years, I assume some sort of common patterns have evolved?) and how to map a few thousand lines of code to modules, files and folders so that the code is reasonably manageable.
(I find 1000-line Java files quite tolerable with an IDE that supports class- and method browsing. I suspect that a 1000-line Erlang file would be rather painful. Especially if there are no tools beyond vi and Notepad.)

(Joe: will be included in new chapter or appendix)

with
enum ShapeType { Rectangle, Circle };
probably should include type square unless you want to show how easy it is to make simple C errors

getting from Z/1 to Double/1 should have been
Double = Z.
rather than
3> Z.
#Fun<erl_eval.6.10732646>
4> Double(4).
8

“badarity” is defined twice in the second-last and third-last paragraphs.

the section heading “crosswords” should be “anagrams”

in the patterns to which the guards apply, or, they are result of applying
one of the guard built in functions in Figure 2.4, on the next page to …

requires a comma after “on the next page”

is “X =/= Y X is not equal to Y”
not identical?

“Suppose we want to want to represent a 16-bit RGB color.” should be “Suppose we want to represent a 16-bit RGB color.”

“I can also hear my disk chattering away. This is a sure sight that the system is paging…” should be “sure sign that the system…”

"apply

“The final step, can be problematic.” - extraneous comma.

Gandalf is spelled with two As.

home.net is a cybersquatter. Suggest example.com from RFC 2606, so we don’t give them unintended hits from cut and paste.

In the explanation of “exit(Why)”: … then the current process will broadcast a exit signal, which argument Why to all processes to which it is currently linked.

Shouldn’t that be “with” instead of “which”?

“a decimal point, a fractional POINT, and an optional” should read “a decimal point, a fractional PART, and an optional”?

(gandalf@falcon.fugal.net)2>
=ERROR REPORT 10-Mar-2007::08:54:40 ===

Connection attempt from disallowed node ‘bilbo@sauron.fugal.net’

I followed the instructions very carefully but the node is disallowed. Same cookie, no firewall, same LAN. Is there some security-related step missing? Erlang 5.5 on Debian and 5.5.2 on OS X.

(Joe says: Very difficult to say what’s wrong. I Googled
this error message and it happens sometimes. Something is
wrong but I don’t know what. The instructions In the book
\t have been tested on my machine and work, and they
should work on other machines. Sound

“The notation Name/N means a function called Name with N arguments.”

Maybe it’s too early in the book but you should mention something about “arity”

First bullet paragraph on the page,
s/single bytes/single byte/
s/sighnedness/signedness/

Explanation of (Line 30) in paragraph starting with “The {packet,2} option”
s/{PicC,{data,[2,45,32]}}/{PicC,{command,[2,45,32]}}/

Under the “Common Errors” sidebar, it starts with “Some guys have mistakenly…” That sounds a bit rough. I’d probably change it to “Some people have mistakenly…” Not all readers are going to be men, or even “guys”.

It would probably help to have an example for the section on the throw() BIF to help distinguish it from exit(). The difference is a bit subtle. I was reading fast through it and had to go back and read it a couple of times before I fully understood why I might want to use one and not the other. Perhaps an example and a recommendation would be best.

In the discussions of working with the exception from

V = (catch shop:cost(socks)).

There are no line numbers next to the shell output, but the text references line numbers. Maybe this a beta book thing, but if it’s not, please add the line numbers as it’s hard to follow.

In the gray box “Force Binary Functions to Return Booleans”, the last paragraph that starts “the answer is…” should be capitalized.

Under character set, it might be nice to address Unicode. Since most modern programming languages are starting to use Unicode internally now, the lack of this in Erlang, while not necessarily problemmatic, is at least conspicuous.

“In all case B traps the error”
Should be cases, no?

In the description of $ syntax, the final sentence reads “Thus $\
is 10$\\∧c is 3 etc.”

There needs to be some punctuation between the “10” and the “\\^c” and the “etc.”

In the sections describing integers and floats, the examples are all given on a single line with only a small bit of whitespace between them. At least in the PDF version, this makes it very hard for my eyes to determine where one number stops and another starts. I’d suggest either putting each of the examples on a separate line, or putting some sort of punctuation between them (probably a comma).

The section on term comparisons has a paragraph that admonishes: "You should also be really very careful about using == (especially if you

Section 5.5, How Long Does it Take to Create a Process

This section starts off saying that the reader may be worried about the performance of sending hundreds or thousands of messages between processes. Yup, that’s a logical question. But the section then goes on to show you how quickly you can created processes. That’s another interesting issue, but it’s not the one the section set up in the reader’s mind.

Perhaps do a full section on performance and cover both message sending/receiving performance, as well as process-creation performance.

Suppose we want to want to

Last paragraph of 2.11: whenever you want to reverse a list you should call lists:reverse any nothing else.

Should be “and”.

So, to build a dynamic a dynamic call to a

Second paragraph of 7.1: The reference seems to be missing. Maybe it’s because you spelled “tolerent” instead of “tolerAnt”?

The footnote tells me:
“1. This is only true for HTTP/1.0, for more modern versions of HTTP a different strategy
is used. ”
Cool. Why not use a more modern version? Google will surely handle the “more modern version”… And it would be useful!

(Joe says: because it makes the program more complicated, and this section is about programming sockets and not HTTP)

In we a remote module, we could refer to square/1 as follows:
- huh

mentioned, but I

sec.code.loadingsec.code.loading.
and
The two most common functions which we use manipulate the
(requires a “to” between use manipulate

Why don’t you simply write

1> apply(erlang, atom_to_list, [hello]).
“hello”

instead of

1> F = list_to_atom(“atom_to_list”).
atom_to_list
2> apply(erlang, F, [hello]).
“hello”

?

Typo in next to last para in section 4.1

“q() is an shell alias for the command init:stop().”

On page 102 you define add_patha and add_pathz but on the next page you use add_patha and add_path without a “z”. Maybe you could mention that add_path and add_pathz do the same job if it is the case.

Exemple is:
$ chmod u+x hello.erl

But in the text below you say:
(on a Unix system give the command chmod a+x File)

This is not wrong but you might want to write it “u+x” instead.

First sentence of section 4.9:
“The Erlang shell has a number of build-in commands,…”

Built-in would be better I think. However I am not a native english speaker.

At the beginning of section 5.1:
“All we we have to do is add the following primitives:”

At the bottom of the page:
“the message sending primitive ! returns themessage itself.”

There should be a whitespace.

“Note: some of these of these are reserved, so your program cannot actually use this number.”

birthday(#person{age=N} = X) ->
X#person{age=N+1}.

Is the corrected code, but this is still too dense for me at this point, and I couldn’t figure out how a pattern could have an ‘=’, I rewrote it for myself to make it more clear, I’m still unsure how ‘X’ is the whole pattern match in #person{age=N} = X, I guess the right side evaluates first as a pattern, and then the result against that goes to the next pattern

birthday(X) ->
#person{age=N} = X,
X#person{age=N+5}.

(Joe: written 2.5 pages on this !!!! - thanks for
pointing out that it was incomprehensible,
in retrospect I agree :-))

Second paragraph under section “Syntax” reads “We can add more than one element to the beginning of X by writing
[E1,E2,..,E2|X]”

Shouldn’t that be something like “[E1,E2,..,En|X]”?

In Section 11.3:
“This returns the IP address and Port of the other end of the connection, so the server can [something missing here] who initiated the connection.”

maybe your web server will be bet-
ter than than the best.

End of page: “By defining it as Pid! ! Pid2 !…”. Should be
“Pid1” (the earlier erratum did not explicitly mention this).

occurances —> occurrences

last paragraph before 1.10

first bullet point
clause. -> clauses.

second bullet point
does handle -> does not handle

"When we

In the gray box in the previous page you just said to rename the module name to avoid name clashing with the standard modules and in this page you present a module named “lists.erl” which obviously is gonna clash. Maybe something like “mylists.erl” is better

A minor problem: "All the possible arithmetic expressions are shown in Figure 2.1. Each arithmetic operation has either one or two arguments

The bulleted list at the top of the page says “list(T) is an alias for [T].” Because we’ve used T in so many places to identify the tail of the list, I was initially confused as to its use in this bullet.

The bullet item for none() states “Strictly it’s not a type…” I believe this fragment needs a comma: “Strictly, it’s not a type…”

In the middle of page 61, the text contains the line “@type newType() = TypeExpression.” When I first read this line, I thought it was introducing new syntax for the language. It was only after reading the note in the middle of page 62 that I realized this line was not valid Erlang.

Item 5 states “…an instance of a predefined type is a type expression.” Because of my background in object-oriented terms, I was confused by an instance being described as a type. After continuing, I understood the phrase; however, “object purists,” perhaps like myself, might find this description confusing.

(Dave says: each area has its own jargon)

I, too, found the explanation of types confusing. Perhaps, instead of presenting the abstract notation first, presenting a concrete example and then “dissecting” it would be clearer.

(Dave says: this will be clearing in the next major beta)

The last sentence of the first paragraph after the list states: “The error is detected and the system….”. I believe this needs a comma like “The error is detected, and the system….” In addition, the next sentence states: “Failing this it tries to…” Again, I believe this phrase should have a comma: “Failing this, it tries to….”

The phrase “…system raises an exception—this is the technical term for….” might be better as “…system raises an exception—the technical term for….”

The last sentence before the new section starts with “If evaluating (catch Expr)…” When I read the sentence, I expected more detail.

Earlier (page 65), in the justification for Erlang’s approach to exception handling, the text lamented having 30% overhead in code devoted to defensively handling arguments to functions.

When I read this code, I wondered, “How does this code differ from defensive programming in other languages?” If the example is to illustrate a point, I think it is important to note that (even in a footnote). If this code is typical Erlang programming style, then a better explanation of defensive programming on page 65 is in order.

(Dave says: have a look at the upcoming exceptions chapter)

The text states “…was caught and corrected in g.” Perhaps “…was caught and handled in g.” might better communicate what happened. (Perhaps I’m being pedantic but I found it difficult to agree that returning 10 was “correct.”)

(Joe says: I’m going to totally remove this)

The text uses the phrase “…message sent over a network etc and…” I was unclear what other things the “etc” might refer to in this paragraph.

The phrase “ie” should be “i. e.”

The next to the last paragraph states “…the shell will print the binary as a string, otherwise it will be printed as…” I believe a semi-colon is more appropriate with otherwise: “…the shell will print the binary as a string; otherwise, it will be printed as….”

The fourth paragraph states “Then we’ll dive into the details of bit syntax expressions, and finally we’ll look at….” I believe the ideas might be more clearly suggested by two sentences: “Then we’ll dive into the details of bit syntax expressions. Finally, we’ll look at….”

The text states: “…must be evenly divisible by 8.” Although the math is simple, I wondered if Erlang provided some way to pad a binary so that its total size was divisible by 8.

(Joe says: No, This is not possible)

spawn_link(Fun) -> Pid
This exactly like spawn(Fun) but in a addition a link between the parent and child processes is created.

This IS ex…
and
but in addition…

some computation, and something goes wrong. How can we identify

a comma or the “and”

and

non-normal exit reason, then all th…

no comma
(heavy duty technical errors here)

The first sentence on the page says “…integer in a certain word size,” I believe the trailing comma should be a period.

The first sentence in the new section states “…a bound variable is merely represented….” I’m unclear if the word “merely” is needed.

The first sentence of the second paragraph states “In Erlang variable values….” I believe it needs a comma: “In Erlang, variable values….”

In the fourth paragraph, the text states “So once we know which variable is incorrect then we can immediately….” It might be more understandable to read: So once we know which variable is incorrect, we can immediately…."

The text states: “…how it’s possible to program without variables,” I believe this trailing comma should be a period.

The last paragraph on the page states: “Don’t get confused here in line one the…” I believe its clearer to break this line into two sentences: “Don’t get confused here. In line 1 the….” (I used the digit for consistency with other line references.)

The C code fragment reads:
if( ret == RET_SUCCESS ) {
…

Since the text elides part of the code, it might be better written on a single line:
if( ret == RET_SUCCESS ) { … }

The last line on the page states: “…there are no macro definitions and….” Although the text is contrasting Erlang with other languages, a footnote referring reader to macros might clarify the distinction between macros and “macro definitions.”

The text states: “If you use a variable in building a new tuple then the new tuple….” It might read better with a comma: “If you use a variable in building a new tuple, then the new tuple….”

The text states: “In command 2 X is bound…” I believe it should read “In command 2, X is bound….”

The third paragraph from the end of the page states: “…must both have the same number of elements.” I believe it might be clearer to state: “…must both have the same number of elements and corresponding elements on both sides must bind to the same value.”

The last paragraph describes the behavior of Erlang when matching fails. It might be valuable, at least for readers familiar with Prolog, to contrast that Erlang considers non-matching an error instead of failing and back-tracking.

The footnote reads: “In a pattern this syntax unpacks the CAR and CDR in an expression it constructs a CONS cell.” It might be more understandable to read: “In a pattern, this syntax unpacks the CAR and CDR. In an expression, it constructs a CONS cell.”

Paragraph starting with “The main entry point”, 7th line in the paragraph,
s/trim the trim the/trim the/

The text of the second paragraph states: “…we’ll return to the shopping list that we introduced in the last chapter and we’ll write some code…” It might read better with a comma like “…we’ll return to the shopping list that we introduced in the last chapter, and we’ll write some code….”

The last paragraph of the opening section states: “…create your own control abstractions. Then finally we’ll talk about….” It might be better split into two sentences: “…create your own control abstractions. Finally, we’ll talk about….”

The first paragraph states “…the body consists of a sequence of expressions, which are evaluated….” In previous places, the text has emphasized that Erlang is a functional language in which everything returns a value. Perhaps a footnote could indicate what is the result of evaluating a sequence of expressions?

The first paragraph states: “…clause order does matter, and when a function is entered the clauses….” This sentence might read better as two sentences: “…clause order does matter. When a function is entered, the clauses….”

All the functions described in the text calculate their result using a single expression. Can a fun evaluate multiple clauses?

The next to the last paragraph states “…or the atom true.” I found myself asking two questions: “What would be the purpose of including true as part of a guard (since it is always true)?” and “What results if a guard includes the atom false?” I think a footnote to address those two questions might be useful.

The first paragraph states “OR-guards are just AND-guards separated by semicolons.” Is the phrase “AND-guards” accurate? (I understood AND-guards to be guards separated by commas.) In addition, if the phrase “AND-guards” is inaccurate, the example “AG1; AG2; …; AGn” should probably be changed to “G1; G2; …; Gn”.

The last sentence on the page reads “…head of the list L…” I believe the trailing ellipsis should be a period.

The last paragraph in the OR-guards section states “The first guard means…” On this page, the last paragraph states “Line 1 means…” I find identifying the guards as first and second instead of referring to line numbers to be clearer.

The first sentence of the Short-Circuit Boolean Expressions states “…only evaluated if necessary.” On reading this statement after reading about AND- and OR-guards, I wondered, “What is the default order for evaluating guards? Is it indeterminate? Are all guards ordered (even after the boolean value is determined)? What heuristics should a programmer employ to determine when to use a short-circuit expression versus other guards?”

I would find a “tip box” very helpful in answering these questions, but something I could skip if necessary.

The third paragraph of the Records section states that record declarations can only be used in modules and not in the shell. The fifth paragraph states “Warning: -record is not a shell command…” These two references so close together seem redundant. Could the text either combine them into a single paragraph or remove one.

The last paragraph describes how Erlang evaluates a case statement. On page 57, the next to the last paragraph describes an if statement and states “At least one of the guards…must evaluate to true otherwise…”

What happens if no patterns in a case statement match?

The next to the last paragraph has the text: “…evaluated as follows: Firstly Guard1 is evaluated, if this….” I believe this sentence is clearer if written like: “…evaluated as follows: first, Guard1 is evaluated. If this….”

The next to the last paragraph states: “If Guard1 does not succeed Guard2… is evaluated until a match is found”. I believe it is clearer if written: “If Guard1 does not succeed, Guard2 is evaluated, and so on, until a guard succeeds.”

The third paragraph from the bottom has the text: ‘…build them in “natural” order, ie by appending elements to….’ I believe “ie” should be “i. e.,”

The last sentence of the next to the last paragraph states: “If you look in the source code for the module lists you’ll find a definition of reverse, but the compiler ignores this definition and uses an internal version which is much more efficient that the version defined in Erlang.”

I’m confused by this sentence. I believe the text might be better written: “If you look in the source code for the module lists, you’ll find a definition of reverse. However, this definition is simply used for illustration. The compiler, when it encounters this definition, ignores it in favor of the much more efficient internal version defined in the OTP standard library.” (I believe the last terms are correct.)

“In line 1 we pattern match the term {tag1, A, B} and line 3 we call f with”…

There should be an “in” before “line 3 we”.

Control+C on Windows immediately terminates the shell rather than displaying a menu.

There are some issues with the second last paragraph. “This is message is…” should probably read “This value is..”. Also, I’m a Erlang newbie, but isn’t the data fragment added to the head of the list rather than “appended”?

The comment for line six says “The we encode…”

You mention that spec and type are only found in documentation files, and are not part of the Erlang language. This should have been introduced earlier when you introduced the @type syntax. Furthermore, the justification/rationale for it not being part of the language (if any) should have been presented.

Bullet point 3: “Type — A a type expression” has one too many a’s.

“we represent by a name by a descriptive variable name” is messed up.

At the top of page 76, explain where the number <<23,180>> comes from. Sure, it’s pretty obvious, but not everyone will get it.

The sentence “This section has three examples from real life all the code here is cut-and-paste from real world programs.” is a run-on sentence.

“Our our assumption was incorrect” is is incorrect.

If you’re going to introduce macros on this page, you at least have to mention what the ?DWORD syntax means.

Don’t assume that people know what IPv4 is, or even what IP is.

“each Erlang process has a local area of the destructive storage” is ungrammatical. “of destructive storage” is probably what you mean.

“Note that only exported function can be called from
outside a module.” should be “exported functions”.

You talk about beam code on this page. Has beam code been mentioned before?

(Joe: yes - page 33 B1.6)

In the box: “which return true or false” should be “which returns true or false”.

What do you mean by a “conventional include file”? It’s not clear what include files buy you (if anything) that modules don’t.

When I read the title of the section, “Building Lists in the Wrong Order,” I thought this section would describe some “natural” programming tendency to avoid.

In my first three readings, I was confused. The text kept telling me to build lists naturally and, if necessary, reverse them later. Because I would tend to do this anyway (perhaps my Lisp and Prolog familiarity), I kept wondering, “What am I missing?”

Finally, after my fourth reading, I understood it was telling me not to “fear” building a list “backward.” Simply build it efficiently backwards and reverse it at the end.

How could the section title change to avoid giving the impression that the “natural” approach is wrong?

The last sentence on the page states “Open File which is string according to…” I believe it should read “Open File which is a string according to…” Another alternative, similar to the next API description might be “Open File (a string) according to…”

Your C code should look like this, so it matches the Erlang version:

enum ShapeType { Rectangle, Circle, Square };
struct Shape {
enum ShapeType kind;
union {
struct { int width, height; } rectangleData;
struct { int radius; } circleData;
struct { int side;} squareData;
} shapeData;
};

double area(struct Shape* s) {
if( s->kind Rectangle ) { int width, ht; width = s->shapeData.rectangleData.width; ht = s->shapeData.rectangleData.height; return width * ht; } else if ( s->kind Circle ) {
…

Note the addition of a return type for the area() function, and the
addition of the return statement for the Rectangle area
calculation. Note also the consistent use of “height” for the
rectangleData member name.

For the Java code, why not use “height” or “ht” for the
rectangle, rather than “length”, just to remain consistent with the
Erlang code?

Apples and oranges cost 2 and 5 units, not 2 and 3 units.

Footnote 6: change “claused” to “clause”

The last sentence in the second-to-last paragraph reads: " (Note: process
<0.43.0> is process B, as it is process B that dies.)"

I really don’t understand what this is trying to communicate in any case, but isn’t the PID wrong (should be <0.44.0> instead of <0.43.0>)? There isn’t a <0.43.0> mentioned anywhere.

The example in the middle of the page where process C is killed notes that the reason is changed from “kill” to “killed”. Indeed, the pseudo-code for the error handling presented a few pages earlier support this. No mention is made on page 139 as to why this is significant, however. Immediate questions that come to mind are:
1. Why does it work that way?
2. Should I care? Is it significant to an application programmer?

Under “Exiting Another Process” the last sentence of the third paragraph reads " This is as a
safety measure to avoid accidently killing more of the system that you
had intended."

This should say “than you had indended.”

Chapter 8, first paragraph: “So far we have see all the parts but not how to put the parts together.” This should read “So far we have seen…”

Here are the results I obtained on the computer I

Typo in footnote

2. io:format understands an extrememly large number of formatting options, the full set can be found in the io manula pages.

Under “The Group Controller” it says “If a message is send the controller it broadcasts the message to all members in the group.” Replace “send” with “sent to”.

"It

Lots of grammar issues in this paragraph:

“The message sequence diagram, show the messages that result from a user typing an line into the io widget message entry region. This results in a message to the chat controller ©, followed by a message to one of the middle men (M1) this goes via M2 to the group controller (G).”

“deign” -> “design”

Just before 2.12: “uses a internal version” should be “uses an internal version” and “much more efficient that” should be “much more efficient than”

The text starting from “Now we can write Erlang modules” doesn’t fit well with the text that precedes it. It sort of jumps out and surprises you. I suggest making it a separate section, just to set it off from the preceding topic.

Spelling mistake in the last paragraph: “caclulation”

In step 3, it currently reads: “This is message is one of the data fragments…” That should be “This message is…”

In step 3, it currently reads: “The third argument in this tuple is a binary, this is because we opened the socket in binary mode.”

There are two distinct sentences there. Thus: “…tuple is a binary. This is because…”

The first sentence of the last paragraph states: “The main reason why we don’t check for errors has to do with concurrency.” The remaining system talks about the separation of concerns in an Erlang system between “workers” and “supervisors.”

I do not understand how this separation of concerns (a good architectural and design principle) affects concurrency and how concurrency affects the way we handle errors.

The third paragraph of the section “The throw() BIF” states: “…within some function F then the result of evaluating….” I believe this reads better with a comma like “…within some function F, then the result of evaluating….”

The first sentence on the page states: “…in our earlier example, we might write”. I believe it needs a trailing colon: “…in our earlier example, we might write:”

The code block at the top of the page defines total/1 and implements error handling by printing message, skipping the erroneous value and continuing processing.

How typical is this idiom in Erlang programming (since it seems very different from conventional wisdom today)?

This actually spans from the last paragraph of 216 to the first paragraph of 218, ignoring the sidebar on page 217. This paragraph starts “1. We called connect(Host, Port, [binary. {packet,0}]) to connect to the…”

Basically, the paragraph describes the binary option again. This was already described twice before when the example was first presented. At this point, I’m really curious not about “binary” but about what other options are possible for this field. All the repetition starts to beg the question after a while (and is redundant).

I believe that the last sentence of the next to the last paragraph, “If an item is omitted then a default value….” might be better written as “If an item is omitted, then a default value….”

The text mentions the “endianness” of the machine. Does this mean that binaries written to the file system or to the network are suitable for moving to different processor architectures?

The first sentence describing Unit states: “…Size x Unit bits long, this value must be….” I believe this fragment should be two sentences: “…Size x Unit bits long. This value must be….”

The description of the unit specifier states: “…this value must be…a multiple of 8.” On my second reading, I found myself wondering: “What does ‘this value’ refer to? Must the Unit value by a multiple of 8? The total size of the binary be a multiple of 8? (Mentioned on page 76) Or must each segment be a multiple of 8?”

The second sentence of the third paragraph states: “We use the information we find there….” It might read better written as “We use the information found at that position…”

The fourth paragraph states: “…we first assume that we are correctly positioned at the start of an MPEG header then we try to compute….” I believe this might be better written as two sentences: “…we first assume that we are correctly positioned at the start of an MPEG header. We then try to compute….”

The last paragraph states: “To catch any errors we wrap the call….” This might be better written with a comma: “To catch any errors, we wrap the call….”

The discussion on “framing” says “TCP socket data is just an undifferentiated stream of bytes. During transmission this data can be broken into arbitrary sized fragments so
we need to know how much data represents a single request. Deciding how to break the input stream of data into logical packets is called framing.”

This is a really inaccurate description. “Framing” in a networking sense has nothing to do with anything at the application layer. Further, the socket API has nothing to do with how TCP data is actually represented on the wire. There is NOT a 1-to-1 correspondence between TCP sends or receives at the API with the packets that actually go out on the wire. The TCP stack is free to coalesce or fragment data that passes through the API before and after it interacts with the wire. The only guarantee that TCP and the sockets API make is that data will be received in order.

The next paragraph then says, “In the Erlang case we use a very simple form of framing and say that every logical data packet will be preceded by a N (1, 2 or 4) byte length count. This is the meaning of the {packet, N} argument in the gen_tcp:connect and gen_tcp:listen functions. Note that the arguments to packet used by the client and the server must agree. If the server was opened with
{packet,2} and the client with {packet,4} options, then nothing would work.”

It took me a while to understand that you were now talking about something very Erlang-specific — the transmission of Erlang terms over the network using an Erlang wire format — and that all this talk of “framing” now had to do with this Erlang-specific wire format. As a person who is well-schooled in the sockets API, this leap in context was not at all apparent. In fact, it was terribly confusing.

The second paragraph on the page states: “…2 bits into B 2 bits into C etc.” I believe a comma is missing: “…2 bits into B, 2 bits into C etc.”

The code block in the middle of the page uses macros to reduce the semantic gap for Windows programmers. Might the example be clearer by showing stepwise refinement leading to the macros? (I believe someone experimenting with the language for the first time would be more likely to not use macros immediately.)

As a long-time datacomm networking guy, I object to the use of the word “packet” on pages 219 - 220 to refer to an application-level concept. At least for me, packets are the things on the wire. Perhaps, I’m being overly pedantic. I realize that there are too few words here to describe the concepts uniquely. I would normally propose “message” but that conflicts with Erlang’s language-level message sending/receiving terminology. Maybe “application message,” “protocol message,” “socket message,” or “request/response.”

The last paragraph states: “Characteristics is a 16-bit word…” I it should read" Characteristics is a 32-bit word…" based on earlier definitions.

The first paragraph states: “The code <> converted Characteristics which was an integer, into….” I believe it is missing a comma: “The code > converted Characteristics, which was an integer, into….”

The third paragraph states: “Using these macros made unpacking the data in COFF format, well I can’t really use the word easy, bit at least it was possible and the code was reasonably understandable.” I believe it is more understandable written as: “Using these macros made unpacking the data in COFF format—well I can’t really use the word easy—but at least it was possible, and the code was reasonably understandable.”

The first sentence states: “apply is used is circumstances….” I believe it should read: “apply is used in circumstances….”

The last part of the first sentence reads: “…when the arguments to the function are not known in advance, but are computed dynamically.” I believe it reads better without the comma: “…when the arguments to the function are not known in advance but are computed dynamically.”

The third paragraph states: “Calling abc:a(..) will result….” UML “aficionados” seeing a function call will ellipses assume it can take any arguments. Perhaps writing “Calling abc:a(5) will result…” will clarify the text.

The text mentions a number of pre-defined module attributes, but it does not mention -record(…) which appears to have the same syntax. Is -record(…) not a module attribute?

Page 85 states that -vsn is a pre-defined attribute. However, the shell output in the middle of the page seems to indicate that vsn is an user-defined attribute. Adding further to my confusion, the output on the printed page contained the term “{version, ”4.4.1“}” left-justified so I thought it was the version and wondered where the 4.4.1 had come from. Finally, when I executed this example in my local Erlang shell, I realized the {version, “4.4.1”} described the compiler (because the “pretty-printing” indented it under the compile term.)

In section 11.2, “Control Issues”, what about non-blocking transmission of data? That is, how can I prevent a message send from blocking if the remote peer isn’t accepting data fast enough?

(Joe: This is not a book about
networking but about
Erlang. At some point I have to cut off the detail.
Digging deeper at the end of the chapter has some
\t reference that might be helpful)

The text and code block describing how to automate extracting (beginning with “If we want to automate….”) the module attributes is better if it occurs after the next three paragraphs describing the shell interaction.

The text states: “attrs:module_info(attributes) returns….” What other arguments does this function recognize?

I found it difficult at this point in the text to understand how to use block expressions. Perhaps this topic is better introduced earlier in the book—perhaps via a sidebar or footnote.

In section 11.2, “Control Issues,” it isn’t clear what setting {active, true/false/once} does for a gen_tcp:listen. Does that put the listening socket into a non-blocking mode? Or are listens always blocking? Does it simply set an option that is ignored by the listening socket but then inherited by every connected socket accepted from the listening socket?

There are multiple valid models to use here, but it isn’t clear from the description which one Erlang has chosen, or even if multiple models are supported by the Erlang API.

(Joe: This is not a book about
networking but about
Erlang. At some point I have to cut off the detail.
Digging deeper at the end of the chapter has some
\t reference that might be helpful)

Since many popular languages today (for example, C, C, C#, Python, Ruby, Java, Perl) use short-circuit evaluation, I believe you need to discuss Erlang semantics of undefined evaluation order whenever you mention boolean expressions (and guards?) to keep reminding readers that the language may be different from the reader’s expectations.

Earlier, the text discusses defining functions using simple expressions, for example, fun 2 * X end. Now, the text uses fun to refer to a compiled function.

Since some languages, like python, have very different performance characteristics when using these two different function references, do you want to mention any performance differences between these two uses?

(Joe: There are no perfomance issues here. Compiled funs
\t have the same performace characteristic no matter how they are referred to.
In general I don’t mention perfomance apart from where it
is important - like
the ets and dets chapter)

The text states: “Variables occurring in macro definition match complete forms…” What is a complete form?

The text states: “Thus it is not possible to use macros like the following:”

Actually, I entered these macros into a module and the call to foo/1 compiled and executed. I did need to change the definition of foo/l to the following:

foo(A) ->
?start a ?stop.

After compiling, executing foo(abc) in the shell produced the result {a}.

The code block near the bottom of the page states: “…io:format(”TRACE ~p:~w ~p~n“…)” Although the text previously mentioned io:format(…), it has not explained the placeholders ~p, ~w and ~n. Perhaps we need to explain these symbols in a footnote with a future reference.

The code block near the end of the page states “-define(TRACE (x), void).” Is void a built-in Erlang symbol? Does it mean “no-op”? Or is it simply an atom?

The shell interaction at the bottom of the pages begins with compiling a module: “c(m1, {d, debug}).” I assume that the term following the module is a compiler option that defines the atom debug to the compiler. Is this understanding correct?

Earlier, the text described the notation Var |-> Value to mean that Var is bound to (unified with) Value. In the description of put(Key, Value), it uses this same notation to describe the result of put/2. Is this an accurate description, or is it more accurate to say that Key is mapped to Value?

The last paragraph states: “As you can see, variable in the process dictionary….” I believe the text should state: “As you can see, variables in the process dictionary….”

The last sentence on the page states: “If you use the process dictionary then your code will no-longer be side-effect free…” I believe this reads better written as: “If you use the process dictionary, your code will no longer be side-effect free…”

The last sentence of the first paragraph states: “For this reason the process dictionary should be used sparingly.” Might it be beneficial at this point to discuss the limited conditions in which using the process dictionary might have benefit?

Figure 3.1 specifies escape sequences for entering octal character codes. Does Erlang, like C/C/C#, provide for escape sequences using hexadecimal codes?

(Joe: no - the text says “all possible ..” and this text is correct
you can’t represent hex in a string only octal)

The last line of Figure 3.1 states that \\C is an escape sequence whose meaning is the ASCII code for C where is an integer code. I found this explanation confusing. Is C the integer ASCII code, for example “\\97” for the character “a”. (This does not appear to work in the shell.) Does this mean that if I supply a character, it will replace it with the (integer) ASCII value? Is it referring to a control character?

The first sentence states: “…discussed in sect.non.dest.assignment.sect.non.dest.assignment…” This reference, I believe is a backward reference. Shouldn’t it resolve itself like other existing references?

The description of orelse states: “This first evaluates Expr1 if Expr1 evaluates to true then Expr2 is not evaluated. If Expr1 evaluates to false then Expr2 is evaluated.” This description might read better as “This first evaluates Expr1. If Expr1 evaluates to true, Expr2 is not evaluated. If Expr1 evaluates to false, Expr2 is evaluated.” A similar comment applies to the explanation of andalso.

I believe the phrase “…(A or B, and, A and B)….” is has an extra comma after the “and.” It should read “…(A or B, and A and B)….” (Tough call.)

The second bullet describing conversions states: “…the arguments are use ”as-is" ie without conversion." I believe “use” should be “used.” In addition, I think the sentence might be better written as: “…the arguments are used ”as-is“; that is, without conversion.”

Last paragraph in the grey box: "Once I

The next to the last paragraph changes perspective. It first uses we then I. Although the tone is informal, might it be clearer in this paragraph if we use a single perspective?

The next to the last paragraph states: “Now we’re actually through with sequential Erlang, there are a few small topics….” I believe this sentence is better split into two: “Now we’re through with sequential Erlang. There are a few small topics….”

The last sentence states: “In the next chapter we’ll look at how to compile….” Might this be improved with a comma: “In the next chapter, we’ll look at how to compile….”

Section 11.2, “Control Issues”: I looked through the rest of the chapter and there are several important TCP concepts that are missing or only touched on briefly:

1. Name lookup.

2. Address handling.

3. Non-blocking sends.

4. Half-close, which is imporant in some protocols.

5. Out-of-band (urgent data), which is critical in some protocols.

6. Socket options in general.

(Joe: This is not a book about
networking but about
Erlang. At some point I have to cut off the detail.
Digging deeper at the end of the chapter has some
\t reference that might be helpful)

In section 11.3, “Where Did That Connection Come From?”, what representation does the returned address have? Is the returned address a string, an large undifferentiated integer, a tuple, or a binary? These would all be possible representations, some better than others in terms of usefulness.

Section titled “Additional Notes on UDP”. There are a couple suspicious statements and possible errors in this section.

On the issue of UDP flow control, while a receiver cannot block a sender from sending, it can allow the UDP stack to drop the error rather than trying to receive it. In fact, after a point this is better than pulling UDP datagrams out of the UDP stack and queing them. If the receiver is really being overrun, it’s better to start dropping packets than to fill up all of process memory with queued packets and then die (whether you’re an Erlang process or an OS process). Thus, the idea of {active, once} and {active, false} UDP sockets actually makes a lot of sense.

Second, while it is possible for a UDP packet to arrive twice, it’s extremely rare in today’s networks. You might note some possible reasons for this in order to help readers accept that this is true. The basic issue is that because UDP is connectionless, there is no way for a receiver to distinguish between two identical datagrams sent by the sender versus a duplicate copy created accidentially in the network because of a hardware or software bug. Thus, the receiver must deliver all received, uncorrupted UDP datagrams to the application. If the application needs guarantees about ordering, removal of duplicates, etc., then the application programmer must create mechanisms to enforce those attributes on top of the raw UDP protocol.

(Joe: This is not a book about
networking but about
Erlang. At some point I have to cut off the detail.
Digging deeper at the end of the chapter has some
\t reference that might be helpful)

I think the guards sections is a bit too brief. After reading it I was left with a number of unanswered questions:

1) Why do guards have their own syntax? Couldn’t they just be boolean expressions?

2) From the description of “andalso”/“orelse”, I assume “and” and “or” do not use short circuit evaluation but this is not explicitly stated.

3) Why use “;” and “,” when you could presumably use bracketed expressions with “andalso” and “orelse” to achieve the same effect?

4) “Finally, a guard can be used as an expression. It will always evaluate to one of the atoms true or false.”. Not sure what this means.

Bottom of page 129, top of page 130:
“Such a processeS is called a registered process.”

In the description of register BIF (top of the page):
“The registration fails if Name has already been used to register a processeS.”

In the example, a message should be printed on stdout.

3> area ! {rectangle, 4, 5}.
{rectangle,4,5}

should be

3> area ! {rectangle, 4, 5}.
Area of rectangle is 20
{rectangle,4,5}

‘.. anlayse it … ’ (in the got_request function) should be ‘.. analyse it …’

Wouldn’t it be a good idea to place the following paragraph earlier in the book as io:format is used often before page 131 ?

"io:format(String, [Args]) prints the the variables in [Args] in the Erlang shell according to the formating information in String. The formatting codes are preceeded by a (~) symbol. ~p is short for

“by” doubled.

“A tail-recursive function can be compiled so that the last function call in a sequence of statements can be replaced by by a simple jump to the start of the function being called.”

I think a dot should end the sentence before the next section begins. Maybe it’s just a matter of style.

“The exit handler is in itself a very useful building block for constructing more advanced abstractions:”

Paragraph just before section 6.3.

“evoked” should be “invoked”.

“The function that is evoked when the function dies can, of course, perform any computation it likes, it can ignore the error, log the error, or restart the application.”

When I try the example, the message does not change to “killed” as written in the code. I don’t understand what is the meaning of that kill thing, even in the pseudo-code on page 138. Maybe i am just wrong.

Instead of
“Process a received {’EXIT’,<0.56.0>,killed} <— changed to killed ”

I have

38> edemo1:start(false, {die, kill}).
Process a received {’EXIT’,<0.115.0>,kill}
process b (<0.115.0>) is dead
process c (<0.116.0>) is dead
ok

(Joe: Cannot reproduce. I just re-tested this. I get exactly
the expected result. I see your output starts 37> …
the 36 commands you did before this might have influenced the result.
trying giving this command as the first thing you do in a new shell.)

“Set up a monitor. Item is a Pid or a regisetered name of a process.”

"To wind up this chapter we

(not sure about the page number…) I would like it if there was a chapter on debugging an Erlang system, i.e. how to use the debugger tool (and maybe invisio also). The ability to debug a flawed program is essential for any programmer and introducing the tools to do this in Erlang would be a nice addition I think.

‘the data send from’ should be ‘the data sent from’

I don’t understand the command:

‘3> example1_lid:st ’

is it a typo?

Control-C kills Erlang run from a command prompt in a command window. In the Erlang window created by Start > All Programs > Erlang OTP …>, Control-C has no effect. Control-Break produces the “BREAK” banner.

The text states: “When you start programming in Erlang you’ll probably…” It might read better with a comma: “When you start programming in Erlang, you’ll probably…”

The text says “The Erlang run-time system makes use of a code auto-loading mechanism.” Although the term “auto-loading mechanism” may be understood by current Erlang programmers, other programmers may be more familiar with the idea of a “search path.” Perhaps the text might be improved by stating: “The Erlang run-time system makes used of a search path to support auto-loading of requested code.”

The last sentence states: “…is actually programmed in Erlang and we’ll talk more….” I think it may read better with a comma: “…is actually programmed in Erlang, and we’ll talk more….”

The first paragraph describes how Erlang tries to find the object code file for a missing module by searching all directories in the current load path. As I read this, I wondered, “Does this search stop at the first matching file, or does it find all matches? If it finds all matches, which match does it choose?”

The text states: ‘Code loading is performed “on-demand”.’ I believe the period and closing quotation mark are transposed: ‘Code loading is performed “on-demand.”’

The text states: “…in a module which has not been loaded then an exception occurs….” This might read better replacing the “then” with a comma: “…in a module which has not been loaded, an exception occurs….”

The text describes the two most common functions to manipulate the load path. As I read the description, I wondered, “What advice would you give a learner/beginner on deciding between these two functions?”

Ah, the Windows “home” directory. Although the home directory is well-known in Unix, Windows has many personalities. (And it varies by Windows version!). Many programs respect the Unix HOME variable set in the Windows environment. Other programs seem to use HOMEDRIVE + HOMEPATH.

I don’t know if you want to discuss these vagaries in a sidebar at this point, or if you want footnote a future reference to init:get_argument/1 so that a poor Windows user knows where to put the .erlang file.

The text describes starting Erlang with a command line to supply additional search path directories. This works if one invokes Erlang from a command prompt; however, if invoking Erlang using the Windows shortcuts, you must edit the properties of the short cut to supply new options.

The requisite magic under Windows is “Start > All Programs > Erlang OTP …” Now right-click the Erlang menu item and select Properties. On the Shortcut tab the Properties dialog, edit the Target field to include the new search directories. However, to avoid destroying the original shortcut, you may want to copy the original link at first.

“Curiouser and curiouser,” said Alice.

‘Tagging program often appear’ should read ‘Tagging programs often appear’

The “Tip” near the bottom of the page describes how to discover what Erlang thinks is its home directory.

Can I do anything to affect that decision? (I prefer not to put these kinds of files in my Windows “home” directory if I can avoid it.)

The text states: “Alternatively you can run your program directly…” It might read better with a comma: “Alternatively, you can run your program directly…”

Some more info on how cookies work would be nice. Are they sent across the network in the clear, or are the cookies encrypted first? Are they used to encrypt all communications?

“This file is automatically created the first time Erlang is run on your machine it contains a random string.” doesn’t flow very well.

The code at the bottom of the page may execute correctly under Unix, but it fails on Windows unless the user has set the PATH variable to include the directories containing the Erlang binaries.

An alternative to setting the PATH variable on Windows is to invoke the commands using a fully qualified path:
“C:\\Program Files\\erl5.5.3\\bin\\erlc.exe” hello.erl
“C:\\Program Files\\erl5.5.3\\bin\\erl.exe” -noshell -s hello start -s init stop

(And, yes, for this path, you need the quotation marks.)

The text says: “…has three component parts:” Might it be better to say: “…has three options:”?

The text states that the two -s options cause Erlang to run the functions hello:start/0 and init:stop/0. When I read this description, I wondered: “Can I supply more than two -s options? Does it execute all the functions in the order supplied on the command line?”

’ to include file,hrl which contains’ should read ’ to include file.hrl which contains’

The text states: “To run the shell script we chmod the file…” This step is necessary for Unices (and cywin). In a Windows environment, one creates a batch file (.bat), the #! trick does not work (although it is ignored), and one must use the full pathname to the binaries if the path is not set.

For example, my batch script is:
#!/bin/sh
“C:\\Program Files\\erl5.5.3\\bin\\erl.exe” -noshell -s hello start -s init stop

The text in the sidebar states: “When you’re developing code it’s a bit of a pain….” It might read better with a comma: “When you’re developing code, it’s a bit of a pain….”

The code for module fac1.erl in the middle of the page mentions a function named main/1. To avoid confusing us poor C/C/C#/Java programmers, you might want to clarify that this name is simply used for familiarity (by us!) and could be anything.

The text states: “I’m not going to explain makefiles in general.” You may want to reference another book or a hyperlink which provides readers unfamiliar with makefiles at all to gain some information.

Although another reviewer mentions that you do not need the target for .yrl files, if you decide to include it, you may want to add a comment about it since the text has not mentioned these types of files yet.

The Makefile.template file might be suitable for Unix; however, it failed to execute using nmake (the incarnation of make provided by Microsoft for the Windows world). It first failed because the module line “…” did not have a trailing \\. It then failed on the compile line.

You may need to provide two different Makefile templates: one for Unix and one for Windows (sigh… so much for standards adherence).

(Joe: No instread I’ll show you how to setup MSYS and MinGW that understand
GNU Makefiles)

Line (1) describes a special target. The text later says that “…some modules need special treatment (for example the module special1 in the template file), so there is a separate rule to handle this.”

Although make gurus will understand that a module only needs one target describing how to build it, make novices may not so a comment before the target in the makefile template might be worthwhile.

The second and third paragraphs give a quick, gentle introduction to makefiles. I think it is beneficial to move this description before the details of the makefile template. This positioning will help “makefile newbies” more effectively “grok” the use and purpose of a makefile.

(Joe: elsewhere I usually start with the example and then explain
\t it - this seems ok here as well)

The subdirs target has two references to dir1. I believe the first reference should be dir1 and the second reference should be dir2.

If a reader has been entering commands in the Erlang shell while following the book, the advanced editing commands described here would have been very useful to have been described earlier when introducing the shell.

The last bullet point describes how to kill the Erlang monitoring process. Although I might be able to find this process on Unix, I’m not even certain what process I would be looking for in Windows.

The word “spelt” is a chiefly British spelling. I’m not certain how you plan to handle British versus American spelling (“spelled”).

Another common problem I have encountered as a “newbie” Erlang programmer: I put periods between function clauses instead of semi-colons resulting in a duplicate function error.

Although it’s simple to fix, it takes getting used to.

The text describes a number of useful commands for the shell. If one is familiar with an interpreted environment, one easily “groks” that these functions return Erlang terms which can be operated upon by other Erlang functions (such as filtering the history list to only review the history item(s) you are interested in). However, if one is only familiar with (most) compiled environments (C/C/C#/Java), it may be unclear how to utilize the information returned by these (and other) “introspective” functions.

A sidebar describing that the results are just Erlang terms (and not simply a “printout”) might help developers understand how to better use these commands.

The text in the middle of the page states: “In line 3 we sent a message….” The text should state: “In line 6 we sent a message….”

The next to the last sentence on the page states: “…primitive ! returns themessage itself.” It should read “…primitive ! returns the message itself.”

The text states: “…the message is usually called a client and the process which….” I believe it reads better with a comma: “…the message is usually called a client, and the process which….”

The text states: “…from the server it will mis-interpret this message….” I believe mis-interpret is not hyphenated. In addition, I believe it reads better with a comma: “…from the server, it will misinterpret this message….”

First bullet point reads “The function area is made up of several dif ferent clause.” It should be “clauses”.

Slight typo, this:

and so the shell prints out {point, X, Y}.

Should read:

and so the shell prints out {point, 10, 45}.

That is, the shell prints out 10,45 not X,Y.

extra trailing ) in first paragraph of section 2.3

The pseudo code for EXIT handling is wrong.
When not trapping exits all non-normal exits lead to death. Processes that trap exits die if ExitReason==kill.

if ExitReason normal then continue; else if ExitReason kill then
broadcast the exit signal “killed” to
all processes in my link set
then die;
else
if process_flag trap_exit == false then
die;
else
add the message {’EXIT’, Pid, ExitReason}
to my mailbox
end
end

Add a lines or two about the special exit reason ‘kill’, and why it is changed to ‘killed’ when propagated. ‘kill’ is untrappable (even when trapping exits), but the propagated signal must be trappable; otherwise, supervision wouldn’t work.

“doris $ erl -name gandalf -cookie abc
(gandalf@doris.myerl.example.com) 1> kvs:start().”

This is actually wrong. It should be -setcookie abc
The reason why it works for you may be that you have a
$HOME/.erlang.cookie file that happens to be the same on both computers. The flag -cookie is obsolete and has no effect, according to the manual (why is it allowed then?)

“When we have two nodes on the same machine we use “short” names (as indicated by the -sname flag), but when they are on different machines we use -name."

Actually, -sname works fine even across machines, as long as they are on the same subnet. Using -sname across machines is also the preferred (only?) option if there is no DNS service.

Re. how to get the same version of the code running on all nodes, there is a very nifty shell command for doing this: nl(Module) will load Module on all connected nodes (make sure they’re connected first, through use of ping/1, for example)

“All the nodes in a distributed Erlang system must have been started with the same magic cookie.”

This is not entirely correct. It is possible to use erlang:setcookie(Node,Cookie) to configure each individual connection. If NodeA has cookie “cA” and NodeB has cookie “cB”, then NodeA must call erlang:set_cookie(NodeB,“cB”), and NodeB calls erlang:set_cookie(NodeA,“cA”). Then, they can connect, even though they have different cookies.

On the try … catch syntax:

“try Func of
Pattern1 -> Expressions1;
Pattern2 -> Expressions2;
…
catch”

Rather than just Func (which of course works), the construct actually allows a sequence of expressions, as evident in the yecc grammar:

try_expr -> ‘try’ exprs ‘of’ cr_clauses try_catch :
\tbuild_try(line(‘$1’),‘$2’,‘$4’,‘$5’).
try_expr -> ‘try’ exprs try_catch :
\tbuild_try(line(‘$1’),‘$2’,[],‘$3’).

The Erlang Reference Manual doesn’t mention this, and it’s (unsurprisingly) not widely used.

You could perhaps specifically mention the fact that, using try … catch, we can pattern-match exactly those errors that we want to catch at each level. This is not possible with old-style catch, which catches everything. With try, we can catch a specific throw(), for example, and let default error handling handle the errors. This is a very useful feature.

This point can be driven home with a special Warning sign. Since _Var is a normal variable, very subtle bugs can be caused by forgetting this and using it as a “don’t care” pattern. In a complicated pattern match, it can be difficult to spot that e.g. _Int is repeated when it shouldn’t have been, causing the pattern match to fail.

While I’m a big supporter of using funs in spawn commands, I think you should mention spawn[_link](Node,M,F,A). There are good reasons to use it in the distributed case, e.g. when the different nodes aren’t necessarily running the same version of a particular module. spawn(Node,Fun) can break in certain situations where spawn(Node,M,F,A) will work fine.

“One of the most well-know and possibly the best is wireshark”

Should be “well-known”.

In the Rectangle class, change

final double length;

to

final double ht;

to match the rest of the code.

“When we’ve finished with a table we can dispose of it with dets:close(TableId) or ets:destroy(TableId).”

It should be “ets:delete(TableId)”

There

with respect to Dave Roberts I don’t think you can
duplicate even a small part of Stevens on TCP in a
book on erlang, if the correspondence with the commonly
document C equivalents is clear that should be enough.
If more pages are available please use them on OTP.

(Joe: This is not a book about
networking but about
Erlang. At some point I have to cut off the detail.
Digging deeper at the end of the chapter has some
\t reference that might be helpful)

Could you describe how to interpret the stack trace output? And maybe the best way to use the stack trace output as part of debugging?

It would be very helpful for Erlang newbies like myself. Thank you.

You should explain why BIFs do impossible things. The book says: BIFs are functions which are built into Erlang. They usually do things
that are impossible to program in Erlang.

I assume the reason is because of side effects.

In 14.4 “public
Create a public table. Any process which knows the table
identifier can read and write write this table.” - duplicated “write”.

“To write our iterator we need a massive world list.” - “world” should be “word”.

Installing on Mac OS X - two points:
1) I haven’t found installing MacPorts scary - there is a proper package-based step by step installer.
2) MacPorts build from source, taking dependencies into account. If the reader doesn’t already know this, he/she will be given the impression, by the way you put “Building Erlang from Source” in the next section, that MacPorts are binary.

"In this chapter *we

The refernce to the figure (10.1 I guess) isn’t correct.

The first sentence of “10.1” doesn’t make much sense:

1. The reference to 10.2 should probably be in parens. It can’t be part of a sentence like that.
2. “resulting” should be “result”

Please give a sidebar covering the use of pwd() and cd() (including the fact that forward slashes are always used, even on Windows). Hiding the information in an appendix is a bad idea. Footnote 3 says "If you have downloaded the code you

The lines:

"Warning

In the line

“To understand why this is true we must ask ourselves what an error is, and how an error makes itself known?”

the ? at the end should be a period.

In the line:

"If I

The lines:

"So, for example, if you want to represent someone

In the discussion of lists, it might be worth pointing out that [H|T] is still a valid value even if T is not a list. You say that in this case [H|T] is “improperly formed” which makes it sound like an error, which it isn’t. I like the term “improper list”.

“Name is an atom. [Otp] is a list options, taken from the following:”
Otp should be Opt.

in the gray box: “Anybody know know the name of the blackboard can read the
blackboard, but only the owner can write on the blackboard.” should be “Anybody who knows the name …”

“Note: An Ets tables which has been opened in public mode can
be written and read by any process that knows the table name.
In this case it the user must ensure that reads and writes to the
table are performed in a consistent manner. ” - ‘tables’ should be ‘table’ and remove ‘it’.

“Note: opening a Ets table with zero otions is the same as opening it with
the options [set,protected,{keypos,1}].” - otions should be options.

“Finally, Ets and Dets tables were origonally designed to be used to
implement Mnesia.” - origonally should be originally.

" We havn

“Atoms can also be quoted. Using the quoted form we can create atoms that start with an uppercase letters…” - delete “an” before “uppercase letters”.

It is good that you point out, on this page, that the shell has powerful features, and refer the reader to a later chapter. It would be even better if you gave the information that’s immediately of value right here: that you can bring back previously entered lines for editing using up-arrow or Ctrl-P.

You write “Sometimes we want to know which integer represents a particular character” to explain why we might write [$S,$u,$r,$p,$r,$i,$s,$e] instead of [83,117,114,112,114,105,115,101] (or “Surprise”). That seems strange - do you mean “You don’t have to know the integer representation of a particular character; you can use $a to represent the character ‘a’, etc.”?

Erland should be Erlang in the first sentance.

You introduce the acronym BIF on paragraph 2 without ever explaining what a BIF is or what BIF stands for. On page 53 you use the term built in function but you don’t introduce the acronym BIF until page 77.

The code following the after keyword is used to for cleaning up after Func.

Shold Be:

The code following the after keyword is used for cleaning up after Func.

namedoc@type@author should probably have commas inserted between the tags.

Remove the duplicate a’s in:

The module edoc exports a a large number of functions

Change “contained” to “containing” in the last paragraph.

“so we now we can step up” I think the first we is not necessary :)

“Make a iterator” should read “Make an iterator”

“Ets tables are c reated by” should read “Ets tables are created by”

Just above section 3.5, change “loose a lot of precision” to “lose a lot of precision”.

Given that this chapter is about exceptions, in section 3.5, wouldn’t it be better if the example in this section caught an exception and used erlang:error to print a more meaningful error message?

(Joe: erlang:error does not print an error it raises an exception)

In section 3.7, first sentence, change “ideom” to “idiom”.

In the last sentence on the page, there’s an extraneous double quote just before the word “instead.”

In “a way of talking about Erlang soure” change “soure” to “source.”

Do not say “Five BIFs” but “The following” or something like that. There are more, for example binary_to_list, that should be mentioned here.

“You’ll find a full list of all BIFs in the erlang manual page in your Erlang distribution or online at … www.erlang.org/manual/erlang.html.”

The target of the URL does not exist

(Joe: this will be corrected)

Examples of integers: 32#wow gives an illegal integer error.

36#wow gives the value listed in the next line.

The code for start_parallel_server spawns a fun to do the listening, while the sequential version does not.

My understanding is that you are trying to show how to handle the parallel processing of a request. I think the initial spawn confuses the issue, since the spawn in par_connect(..) causes the parallel processing to take place. [Unless I have misunderstood something ..]

2. We wrote the code…
When all the fragment[s] have arrived and the socket is closed
we reverse the list and concatenate all the fragments.

“All the guard predicates are shown in Figure 2.2, on the following page and the guard term comparisons are shown in Figure 2.3, on the next page.” — this way seems the figures are in two separate page but they are on the same. So I guess “are shown in Figure 2.3, on the same page.” is more correct

10> needs a period at the end.

After 14> (the code block), the two paragraphs basically say the same thing, i.e. programming this way leads to short, easy to understand programs.

“Programs that use operations like map and filter will lead to programs which are short and easy to understand.” and a few lines after “Using list-at-a-time operations makes our programs small and easy to understand;”. Maybe you want to eliminate one of those, it’s a repetition …

Getting Started, 1.6 “Variables”, pp 14 of 24, from PDF excerpt

“we know that X+Y=10 and X-Y=2, then X will be 6 and Y will be 2 in both equations.”

be 4 in both equations.

Getting Started, 1.6 Variables, pp14 of 24, PDF Excerpt.

“Lhs = Rhs really means: evaluate Rhs then match the result again the pattern Lhs.”

result against the pattern Lhs.

Getting Started, 1.6 Variables, pp14 of 24, PDF excerpt.

“Now a variable, such X, is a very simple form of pattern.”

such as X

The sentence “They have
nothing to do with each apart from a co-incidental use of the same
name.” should probably read “They have
nothing to do with each other apart from a co-incidental use of the same
name.”

The word process (which is split with the previous page) is misspelled as “processe”.

“5> Hypot= fun(X, Y) -> math:sqrt(X*X + Y*Y) end.” doesn’t follow the convention that the other pattern matching statements seem to use… “Hypot=” should probably read “Hypot =” (with a space before the equal sign) to match your other examples.

“10> Even = fun(X) -> (X rem 2) =:= 0 end” is missing the dot after the word “end.”

Last line: “If non …”. I think it’s none, not non.

Last sentence: “that wil make your life easier.” it should be “will”.

The example shows that “Mem = <<Red:5, Green:6, Blue:5>>.” produces <<23,180>> but the text states that the shell prints the result as <<23,189>>.

In the sentence “Size must be an an expression which evaluates to an integer” change “an an” to “an”.

In the server code configuration file the service is called ‘nameService’ while in the rest of the example it is called ‘nameServer’.

In the sentence at the top of page says “Guards can be used …, or they can be used at any place in the language where an expression is allowed.” This is NOT true for OR-guards forms, they can only be used in proper guards. The short circuit boolean are equivalent in this case and can be used everywhere.

Should you mention the old forms of the guard predicates, those without is_? While they shouldn’t be used people might run into them in old code. Not worth more than a short comment or footnote though.

In the sentence “A socket provide a stream of bytes between two applications how these applications interpret these bytes is up to the application.” shouldn’t there be a comma between “applications how”?

(This is not specific to this page, but is general to the whole book — I put it here because it’s the first page in the PDF that allows you to report errata.)

There are many sentences in the book in which you use the word “which” when you should really use the word “that.” See the Chicago Manual of Style for an explanation:

www.chicagomanualofstyle.org/CMS_FAQ/Whichvs.That/Whichvs.That01.html

I suppose the copy editor will fix these, but in my experience it’s better to get them right yourself rather than relying on copy editors to do it for you.

(Joe: I’m Englishman - but you’re right.
The publisher says it should be US spelling
and usage - and we’re working at it.
I learn’t in school that 95% of the
time “that” should be replaced by “which”.
Somewhere along the line these problems
will be fixed either by my or later
with the help of the copy editor. Right
now I’m concentrating on the technical bugs)

This bit:

“”“In the Java code an instance of a circle is created by code in the Circle class, but in Erlang circles can be created anywhere in the code.”“”

Doesn’t really make any sense to me. I can say “new Circle(4.0d)” anywhere. You could argue that it’s possible to have functions that extend circle/square/rectangle anywhere, and that would make a little more sense, but with Erlang’s type system, those seem more like the equivalent of static methods on a utility class than extensions of the type. (If this was Haskell, I think your point would be made by the ability to make pre-existing types instances of a type class.)

In the second dot point you refer to the “byte sequence [1, N]” and you say “the 1 means call the function sum” but this dot point is talking about the twice function.

The third dot point has you encoding “sum” as [2,N,M} instead of [2,N,M].

Where do example1_lid and ifconfig come from in the MODS line of the Makefile?

On 13.1 Using TCP, you show a simple http client example. Wouldn’t it be nice to tell readers that there is a more sophisticated http client implmentation already in the library? (e.g. http:request(“”).

The way I read the pseudocode description of receipt of exit signals, it looks like system processes do not receive messages corresponding to normal exits of linked processes. I’m pretty sure that’s wrong.

(Joe: I’ve added more explanation)

signifance

The last paragraph seems disjoint to the page. I think it should be moved to section 7.1 since it seems a bit more appropriate there.

Are there supposed to be line numbers in the statement “(lines to )”?

Should have a space between } and Pid in {Pid, Reply}Pid.

It might be a good idea to mention that Name is an atom. Otherwise someone (like me) may try to use a string.

Typo: “effect” should be “affect” in “Any fatal error in the linked-in driver will crash the Erlang system itself and effect all processes in the system.”

I really think that tail recursion should be introduced much earlier. It is an important concept to know about from teh get go.

Footnote 2: “Epressions” should “Expressions”

First line: “Epressions” should be “Expressions”?

“If non of the patterns match then an exception is raised.” should be “If none of the patterns match then an exception is raised.”

Drop “too” in the following sentance in Paragraph 2:

If a process linked to a system process exits for some reason, the system process is not automatically terminated too.

Drop the comma in the following sentance in the 4th paragraph:

The exit handler is a process that evaluates a particular function, when some other process crashes

The sentence toward the end of the page: “In we wish to call a function ….”, should read “If we wish ….”.

At bottom of page the example code:

double(L) -> lists:map(fun x1:square/1, L).

with explanation:

fun x1:square/1 means the function lists/1 in the module x1.

The explanation should read:

fun x1:square/1 means the function square/1 in the module x1.

In the discussion about lists: “this is very inefficient and only acceptable if the list is very short, and if this is not done in a loop.”

This is worth clarifying, since it will throw those new to FP. A list is a value composed of two values, one for the head element and one of the list that is the tail. Adding an element to the end of the list means that you’re changing every tail value that makes up the nested structure of the list!

(Joe says:this is too much detail at this point in the book)

Distributed Erlang

a minor one :) it should be “U” in the text below

"Socket-based distribution

“Before we do this we start two terminal windows on the on the two different machines.”

This bit syntax stuff seems to come out of nowhere. You need to provide a far better up-front explanation of exactly why anyone would care about it, why it’s in the language, why it’s useful, etc. It reminds me of C/C bit fields, a feature typically used only by programmers dealing directly with hardware or OS kernel structures.

I think it’d be good to highlight how to find and share code libraries for and in Erlang.

The book includes great coverage of Erlang-proper, but I’m coming from the land of .Net, Java, and Python, and it’s pretty discouraging to think I might need to write the millionth HTTP library.

Is there something like Ruby’s rubyforge or Python’s Cheese Shop? If not, there should be, and this book would be a great chance to introduce it.

I suspect you will sell a lot of this book, but my concern over libraries tempers my interest in the language.

(Joe: Read about CEAN page 1.2 (this (we hope) will be like
CPAN or CTAN) also there will be a resources appendix)

In description of the Chat Server (S), “The group server is a single process” should be “The chat server is a single process”

“On a windows system” should read “On a Windows system”. (section 1.2 below first code example).

"Most of the library function assume that lists are properly formed and won

The code listing for the function seq_loop/1 in the Sequential Server ends the initial line for the function declaration with “,” instead of “->”

Variables X and Y are being reused in expression 2. By this point, the reader has not been informed that he can forget the bindings with f(), and it was suggested on p10 that the reader enter the examples exactly as they appear in the text.

glurk:oops(1,23).
The indentation of the error message is not correct.

“All these commands are define”. Should be “defined”.

One should not confuse deep character lists as recognized by io_lib:deep_char_list() with I/O lists (which can contain binaries). iolist() is explained in erlang(3).

“or even, @spec file:open(string(), mode())”. Should be “[mode()]”.

“binary(FileName)”, “integer(Index)”. These guards are deprecated. Use “is_binary” and “is_integer” instead.

“ok = dets:insert(”. Perhaps test if lookup() or insert() returns an error tuple.

“ok = dets:insert(”, “ok = dets:close(”. “exit(eEtsOpen)” should perhaps be something else.

dets_file() -> this_dir() “/filenames.dets”.
could be
dets_file() -> filename:join(this_dir(), “filenames.dets”).

…“open two terminal windows and start two Erlang systems:”
Should be “…systems.” (a dot).

“As we can we can see the program works…”

“…the client is running in one node and the server running in a different node.”. The phrase “on a node” has been used more often in the text.

End of page:
“but when they are on different machines we use -
name.”.
Badly placed newline.

End of page:
“…BIF will be send {nodeup, Node} and {nodedown, Node} messages…”.
Should be “sent”.

“Returns true if the local node is alive; and can be part of a distributed system. Otherwise, it returns false”
Superfluous “;”, missing “.” (dot).

“In addition send can be used to send messages to a registered process…”
The first “send” should have some other font.

“Two modules is the standard distribution cover most needs.”
Should be “in the”.

The sidebar at the top of the page uses an example of traffic lights for a boolean expression. Traffic lights are not a good example here, as they generally are tri-state devices (green, yellow/amber, red), at least in some parts of the world. Please choose another example.

“lists:seq(N)” should be “lists:seq(1,N)”

short-cut expression has been explained in Page 55 “Guards”.

Last paragraph, second sentence “Each frame has it’s own” should be “Each frame has its own”.

In the code below “cd;” should be replaced by “cd /;”

So to destroy your system all you

Second paragraph from the end starts off “Not only is this code beautiful. It is also highly efficient.” I don’t think this is a congruent usage.

Figure Figure 11.1

2 typos.

“ID3 tags were invented by a progrmamer called Eric Kemp to store meta-data desribing the content of an audio file.”

Typo in the sentence below: “find all the by…”.
Moreover in the code listed on page 209, the function lib_misc:find is not used. It is rather lib_find:files.

“The first thing we do is find all the by calling lib_misc:find(Dir, ”*.mp3“, true)”

“compete” should be written “complete”.

There is no such complete list in section 12.3. Moreover that text is written in section 12.3. Not too useful to make a reference to section 12.3 when in section 12.3.

"You

Bottom of the page.

“To find out about a file F we call file:read_file_info(F) this returns {ok, Info} if F is a valid file or diectory entry”

"To find out about the individual files in the directory listing we

“Specifies the endianess of the machine” is a bit misleading - it’s the endianness of the format. As you know, one might well use /big to communicate between two little-endian machines. Printing {<<16#12345678:32/big>>, <<16#12345678:32/little>>, <<16#12345678:32/native>>, <<16#12345678:32>>} in the shell might be a useful illustration.

In unpack_header() you use the old catch syntax, having told the reader not to use it in the previous chapter

The table of arithmetic operations might perhaps be one good place to introduce the 16#deadbeef notation for non-decimal integer literals - I would guess 99% of non-Erlang speakers will be expecting to use 0xdeadbeef instead. Or it can go somewhere else, but should go somewhere reasonably early on.

I found chapter 3 to be somewhat less satisfying than the surrounding chapters. It’s a lot of detail early on (the sequencing of material in your previous Erlang book was superb pedagogy, this seems more random) and people can get a long way through Erlang programming without having to grapple with this stuff. You also vaguely allude to the debate about whether to return {ok, Val} and pattern match or whether to return Val and throw an exception, but without giving any clear guidance. The main impression one is left with IMHO is that Erlang is complicated because of all this and it’s hard to know what to do.

(Dave says: we hear you—it’s changing)

Showing how to generate a stacktrace is useful for semi-experts; the bigger problem for newcomers to Erlang is not being terrified of the little blighters in the first place. Even the very first error messages on page 18 are pretty intimidating and opaque until you know how to read them. Maybe a bit of early hand-holding on at least not being freaked by these would probably go a long way, and then once arities, export syntax etc is understood, going into more detail in reading error reportrs and backtraces might be useful.

For embedded systems, mentioning SASL at least in passing might be useful, for more detailed error reports.

(Joe: in new appendix - sasl has been described now)

Other than a single instance on p.68, this is the first time comments have been introduced. Given how the first two chapters are very good for people who haven’t even fired up the shell before, this is rather late to be learning this basic information.

Chapter 4 (like chapter 3) also has an air of “eat your greens before you’re allowed desert” about it - the dedicated will plough through it, but it’s not inherently about the exciting stuff that draws on to Erlang in the first place. In both cases, is there any way in which an abbreviated “this is the stuff you REALLY have to know before we go on” chapter can go here, and move the more reference-type material later on? Otherwise people might just put the book down before they get to the really juicy bits.

“In Erlang all syntactic constructions are technically expressions.” No they’re not, otherwise you could do everything in the shell that you can in a .erl file, as per the recent thread on erlang-questions. There are also declarations, such as function definitions.

In the sentence in point 1, you spell the first instance of “open” in lowercase but the second instance is capitalized. The second instance should also be lowercase “open”.

“Why Does Single Assignment Make My Programs Better?” - I’m afraid the example of changing pi, whilst amusing (can’t insert hyperlinks, google for “should the value of pi change”) isn’t really that convincing to, say, C progrmmers who would always use a macro for that. However, if you can talk more about side-effect-freeness and how this allows scaling up with multiple processor cores (passing messages can reduce to simple pointer passes within the VM) and better modularity/unit testing, you’re hitting far more buzzwords-du-jour. I don’t know if enabling simpler soft-real-time garbage collection is worth mentioning too - Java has RT extensions now too, so posssibly not.

(Joe says: will be addressed in a new introduction)

Last sentence should start “On a windows system” or “On a Windows system”.

Second paragraph from the end that starts “I’m not a fan of clutter…” should terminate with a period after “… not relevant to my application.”, then start a new sentence with “This results …”.

“Erlang can sometime be …” should change to “Erlang can sometimes be …”.

All of the bullet points at the bottom of the page end in a period except the first one.

First paragraph under My Makefile, third sentence should change from “…deal with most common…” to “..deal with the most common…”.

All of the numbered bullet points in the middle of the page end in a period except the last one (“I type c 2 which…”).

First paragraph under section 6.9 reads “… built-in commands, You can…”. The comma should be a period.

“…just create a module called user_defaults” - should be “user_default”.

On p. 56, it says that “A >= –1.0 andalso math:sqrt(A+1) > B” is an example of guards.

However, it isn’t a legal guard expression. When it is used in an if statement, the compiler thinks it is an illegal guard expression since it uses an external function(math:sqrt).

It would be nice if you explicitly marked that external functions can’t be used in an guard expression.

The text states: “Having received a message the process prints….” I believe it might be better with a comma: “Having received a message, the process prints….”

The next to the last paragraph states: “…prints out the Width and Ht.” I believe it should state: “…prints out the area.”

The first line of the page says, “If we send the process a message….” I believe it should say, “If we send a process a message….”

The last sentence in the first paragraph states: “This is performed by the last part in the receive statement.” Might “part” be better described as “clause”?

The second paragraph states: “When the client wants the server to do something it sends a message….” I believe it reads better with a comma: “When the client wants the server to do something, it sends a message….”

The text states: “In the previous program, all that was needed was to send a message to a process, then receive and print that message.” Perhaps it reads better as: “In the previous program, all that was needed was to send a message to a process which received and printed that message.”

The text states: “Now what we want to do is…p” It may read better with a comma: “Now, what we want to do is….”

The text states: “The trouble is we do not know who to send the reply to.” I believe it reads better as: “The trouble is, we do not know to whom to send the reply.”

The text states: “…the client has to include an address that the server can reply to.” I believe it reads better as: “…the client has to include an address to which the server can reply.”

The text states: “So the sender must include a reply address This can be done….” I believe it is missing a period: “So the sender must include a reply address. This can be done….”

The text states: “Then we have to change the code that receives the message from” I believe it might read better like: “In order to respond to the message, we have to change the code that receives the message from”.

The text states: “…sends the message is usually called….” It might read better as: “…sends the initial message is usually called….” or “…sends the initial request is usually called….”

The text states: “…we send a message to the server, and then wait for a reply, but we do not wait for a reply from the server, we just wait for any message.” It might read better like “…we send a message to the server and wait for a reply. But we do not wait for a reply from the server; we wait for any message.”

The text states: “So if some other process sends the client….” It might read better without the “so,”: “If some other process sends the client….”

The text states: “…while it is waiting for a reply from the server it will misinterpret….” It might read better with a comma: “…while it is waiting for a reply from the server, it will misinterpret….”

The text states: “…so in the pattern { Pid, Reply} Pid is bound and….” I believe it needs a comma: “…so in the pattern { Pid, Reply }, Pid is bound and….”

The text states: “…where the first element is Pid. all other messages….” I believe it should read: “…where the first element is Pid. All other messages….”

The text states: “…other messages will be queued (receive provides what is called….” I believe it requires a period: “…other messages will be queued. (receive provides what is called….”

The text reads: “To run this we call the functions….” It might read better with a comma: “To run this, we call the functions….”

The text reads: “send does not send a message….” It might read better like: “send does not actually send a message….”

The text states: “When you send a message to the process the message is put into….” It might be better with a comma: “When you send a message to the process, the message is put into….”

The text states: “If the match succeeds the message is removed….” It might read better with a comma: “If the match succeeds, the message is removed….”

The text states: “…in the mailbox match, then the processes is suspended….” I believe it should state: “…in the mailbox match, then the process is suspended….”

Throughout sections 7.1 to 7.4, we refer generically to messages and to clients and servers. At a number of points, I was confused as to which message was sent by which process. It might be better to use the terms request and reply or request message and reply messages.

The first full paragraph states: “Sometime a receive statement….” It should read: “Sometimes a receive statement….”

The text states: “…for a number of reasons, there might be….” I believe it should read: “…for a number of reasons. For example, there might be….”

The text states: “To avoid this problem we can add a timeout….” I believe it reads better with a comma: “To avoid this problem, we can add a timeout….”

When I first read the description of receive with a timeout, I was confused about “when the clock started.” I believe it states when the system begins evaluating the receive statement; however, in particular when I was trying to understand receive within a loop, I kept wondering if the timer reset at every message.

My lack of understanding may reflect my C / C / Java understanding of timers.

The text states: “Without the timeout clause flush_buffer would suspend forever….” I believe it reads better with a comma: “Without the timeout clause, flush_buffer would suspend forever….”

The text states: “…the first message in the mailbox, and if there is…” I believe it reads better as two sentences: “…the first message in the mailbox. If there is….”

The text states: “If there is a message matching { alarm, X } then this will be….” I believe it reads better with a comma: “If there is a message matching { alarm, X }, this will be….”

The text states: “…then this will be returned immediately….” It might read better like: “…then this message will be returned immediately….”

The text states: “…this will be returned immediately, remember the….” I believe it reads better as two sentences: “…this will be returned immediately. Remember the….”

My previous suggestion stated “Remember the after section….” I believe I forgot a comma after the word, “Remember.”

The section introduces client-server architectures. For developers used to Web programming, the term “client-server” conjures images of a PC / browser and a server node. It might be useful, to describe client-server more generally and to emphasize that the roles and client and server can change depending on the services being requested.

In section 7.6, the text describes the operation of receive with a timeout. Section 7.4 contains a step-by-step description of how receive works.

To better explain how the timeout and message pattern matching work, it might be clearer if the text either describes how to modify the previous step-by-step description or to include a revised table.

The next to the last paragraph states: “…which want to communicate with this processes.” I believe it should read: “…which want to communicate with this process.”

The text on the first line states: “cesse is called a registered process.” It should read “cess is called a registered process.”

The text states: “Once the name has been registered we can send it….” I believe it is better with a comma: “Once the name has been registered, we can send it….”

The footnote states: “…the full set can be found in the io manual pages.” Although Unix developers will understand how to find this information, Windows developers will not. Windows developers need to open the installed Erlang documentation and select the “stdlib” link on the left-hand frame.

(Joe: described on page 126 getting help)

The text states: “Next we’ll look at error recovery, and see how….” I believe it reads better without the comma: “Next we’ll look at error recovery and see how….”

Fourth paragraph, second sentence should be changed from “…shows how to use these mechanism…” to “these mechanisms” or “this mechanism”.

Extra word “as” in “…send it a message as like this:”

The text states: “…the exit signal will cause it too to exit.” I believe it reads better with commas: “…the exit signal will cause it, too, to exit.”

When I first read the description of an error signal and saw the form in the diagram on page 139, I thought an error signal was a message. I did not understand that an exit signal is NOT a message until several readings of the text (and some experimentation on my own).

I believe that this chapter contains the first mention of a signal. Perhaps the text needs to introduce that concept before talking about linking processes?

The text states: “In part (b), B dies, and in © an exit signal is sent to A.”

I understand that A receives an exit signal whether or not it is a system process. If A is a system process, it converts that signal into an exit message. Is this understanding correct?

The text states: “…that evaluates a particular function, when some other process crashes.” I believe it reads better without the comma: “…that evaluates a particular function when some other process crashes.”

The code listing uses filelib:is_file(File) while the explanation references filelib:exist(File).

Paragraph starting with “In this code”, 5th line
s/there can’t by/there can’t be/

Suggest to explain get_next_word() function a little bit, especially the meaning of the third parameter. My understanding is: L is the character list accumulated so far, with characters reversed.

The text of the last paragraph begins: “When a process exits we might want to perform….” I believe it reads better with a comma: “When a process exits, we might want to perform….”

The text of the first paragraph states: “Finally, when the process dies an exit signal….” I was unclear which process was referred to at first; I had to read the section a second time and examine the function code. Second, I believe the fragment reads better with a comma: “Finally, when the process dies, an exit signal….”

The last paragraph of the section states: “…perform any computation it likes, it can ignore the error, ….” I believe it reads better with a colon: “…perform any computation it likes: it can ignore the error, ….”

The last sentence of the first section states: “The choice is up to the user.” I believe “user” should be “developer,” “programmer,” or “system.”

The first sentence on the page reads: “…machine—in distributed Erlang (next chapter) we’ll see that….” I believe it reads better as two sentences: “…machine! In distributed Erlang, described in the next chapter, we’ll see that….”

The text on exit signals states: “…divide a number by zero the exit reason….” I believe it reads better with a comma: “…divide a number by zero, the exit reason….”

The text on system processes states: “…from a process Pid then the exit signal….” I believe it reads better with a comma: “…from a process Pid, the exit signal….”

The text of the last paragraph states: “…it receives an exit signal ExitReason from….” Since the preceding text has used the atom Why, it might be clearer to replace ‘ExitReason’ with ‘Why.’

The last full sentence on the page reads: “Now we’ll run the program and generating different exit signals in C and observe the effect in B.” I think it reads better as: “Now we’ll run the program generating different exit signals in C and observing the effect in B.”

The last sentence on the page reads: “As we run the program it might be helpful….” I believe it reads better with a comma: “As we run the program, it might be helpful….”

The first paragraph states: ‘…the “before” part shows the processes…." I was initially uncertain where to find the “before” part in the diagram. Perhaps it is clearer if it reads: ’…the “before” part (at the top of each diagram) shows the processes…." Similarly change the “after” part to mention the bottom of the diagram.

The second paragraph states: “…that cannot trap exits:” I was unclear if it cannot or if it simply does not. (I think of “cannot” as implying some kind of authorization or outside agency instead of a programming choice.)

The text states: “As it exits, B then broadcasts the unmodified exit signal….” It might read better like: “As it exits, B broadcasts the unmodified exit signal….” In addition, “broadcast” might be better as “re-broadcast.”

The text states: “A (which is trapping exits) receives….” It might read better with parenthetical commas, “A, which is trapping exits, receives….”

The text printed in response to command three begins with the line “Error in process….” Because the rest of the output text is generated by the code, I was at first unclear how this line was generated.

Perhaps the text needs to remind the reader that an error results in printing the error message.

The text states: “…when a run-time failure occurs a run-time failure….” I believe it is better as two sentences: “…when a run-time failure occurs. A run-time failure….”

The text states: “…is something like devision by zero, or calling a BIF with an argument of an incorrect type, or….” I think it reads better without the first “or” as follows: “…is something like division by zero, calling a BIF with an argument of an incorrect type, or….”

The text states: “…a run-time failure is something like…completing evaluation of the function it was spawned with.” I am unclear how completing evaluation of a function is a run-time failure.