Errata for Programming Erlang

#29186: This is not specific to any page, but I feel that more attention needs to be paid to Erlang's string handling performance and techniques. The book mentions that binaries should be used as much as possible, and shows an example of parsing URL's from a text file, but it does not go far enough.

Based on my reading on the Internet and my own explorations, Erlang string handling (lists of integers) is both very slow performance-wise and extremely inefficient memory-wise (at least 16 bytes per character on 64-bit systems). String handling is a big deal in these days of the Web, and I know of a Web server (Yaws) written in Erlang, so obviously some people think it is suited for these types of applications.

I looked at the source code for Yaws and it seems as though it is doing some clever things with string data to get good performance, but my lack of Erlang knowledge really hamstrings me and I'd like more guidance from the book.

I was hoping that Joe would add a section (or at least a few more paragraphs) to the book on string performance and how to maximize it. I hope the answer is not something like "don't use Erlang for applications that do heavy string manipulation"!--Edwin Fine

#29127: Because erlang is mainly for embedded developer interesting, mabe you could note some common size/memory footprints and in this context point out of a minimal erlang configuration (standalone "sae") --Marcello Presulli

#29170: I'm new to this, but I note in the transition between the section on tuples and lists, no real explanation is given as to the difference between a tuple and a list. It seems from the examples on p.37 and p.38 that I could use a tuple to hold a sequence of atoms, or I could use a list. So when would I choose a tuple, and when would I choose a list. It might be worth a "sidebar" section on - "The difference between tuples and lists ...", or something.

Anyway just a suggestion from an erlang newbie.
--David Peterson

#29215: As someone with a Haskell background, I found the section about 'list comprehension' quite understandable. However I noted that my fellow colleagues (who also enjoy the book very much!) did not reallly understand it with the perms example alone. I explained it to them with a simpler example at first, which opened the door to understanding perms:

mychar([]) -> [[]];
mychars(L) -> [ X || X <- L ].

Thus, mychars("abc") results in ["a", "b", "c"]. A colleague did not understand this at first, thinking a 'list comprehension' [ X | Y ] always needs a form of recursion to 'generate' a list of elements...

Hope this helps,

I might have been a bit vague on the explanation, I can be reached at bkok@ebay.com--Bas Kok

#29718: Paragraph 5 ("If you ever see code like this...") doesn't really explain the problem, and makes it look like "++" is inherently bad somehow.
Suggestion: "If you ever see code like this (List ++ [H]) where List is the ''accumulating part'', it should set alarm bells off in your brain. It means that every time around in the loop, the ++ (append) operation has to do more and more work.{Footnote: This causes the dreaded ''quadratic behaviour'' in programming, and can really sink your program.} This is because ++ has to go through the list on the left hand side and create a new list that simply uses the right hand side as its tail. It is much cheaper if you build the new list by adding to the left hand side, and reverse the result when you're done."--Richard Carlsson

#30327: I think there should be a statement to clarify that the function odds_and_evens() use 'commas' in the body as it is made up of 'sequence of expressions'.

It took me some time to wonder why the function body use 'commas' instead of semicolons. The previous pages that introduce 'functions' in erlang did not touch on this point, and most of the examples of function body are only one-liners.

#28933: I'd like to see a list of short exercises for the reader to do at the end of each chapter or throughout the chapter (with possible solutions) so that the reader can really test their understanding of what was taught in that section.--Saimon Moore

#29255: 4.7 -> Catching Every Possible Exception:
you mention there 'tags', but from reading the book so far, I have no clue of what tags are... ( _:_ vs. _). If would be nice if there was a link to the section where tags are being discussed in the book, e.g. "we'll be discussing tags at page X...".

#29723: Paragraphs 4 and 5 both start with the same sentence: "To find the sync point..." (only the last word differs). In any case, those two paragraphs are verbose, repetetive, and hard to follow.
--Richard Carlsson

#29724: The attributes "-compile(...)" and "-vsn(...)" are described as "predefined module attributes" along with "-module(...)" etc., but in fact, they are technically just user-defined attributes. They can be viewed as pragmas that some tools may or may not care about. For example, the Erlang compiler looks for -compile() attributes, but this is not part of the language in itself - it's just a feature of that particular tool.
Furthermore, it might be worth mentioning that if you don't specify a value yourself for 'vsn', the compiler fills it in for you with the MD5 sum of the module.--Richard Carlsson

#29725: The subsection on Boolean Expressions should have a reference to the subsection on Short-Circuit Boolean Expressions on page 115, and vice versa. The "Note:..." part in the Short-Circuit section would be better to have in the normal Boolean Expressions section (together with the crossreferences).--Richard Carlsson

#29727: Subsection "Control Flow in Macros": This talks consistently about control flow "within a macro", "inside a macro definition", etc. But in fact, you cannot write these things *within* a macro.
Suggestion: Break it out from the Macros section, change the heading to "Preprocessor Control Flow", and talk about "During preprocessing" etc. Also, use the term "processed" instead of "evaluated". Finally, it would be a good idea to note explicitly that one cannot write e.g. "-ifdef(x)." or "-endif." _within_ a function definition or any other declaration, but only before or after.--Richard Carlsson

#29358: "References are globally unique"
As far as i remember that means more than inside of one erlang machine.
Would be nice to give more details, e.g. Can i be sure that this ref will never be reproduced in any cluster whereever whenever of which name ever?--Falko

#31251: not equivalent example

"C:\Program Files\erl5.5.3\bin\erl.exe" -noshell -s hello start -s init stop

#!/bin/sh
erl -noshell -pa /home/joe/2006/book/JAERANG/Book/code\
-s hello start -s init stop --Alexey Kuznetsov

#31565: The concept of a mailbox is referred to and relied upon halfway down the page, but it is not introduced and described until p145, which is also the only place referred to by the index.--Kevlin Henney

#29002: I thought the section on Selective Recieve went a little fast.

Since message passing/recieving is such a large portion of the language perhaps another example program would have been good here.--Chris Holliday

#29803: Section 8.10, "Spawning with MFAs": It is a misconception that spawns using funs would somehow cause problem with dynamic code loading. It is not! The fun is just used as a launch point when the process is created, and the body of the fun typically just tail calls immediately to another function which is where the new process actually lives. Hence, the spawned process will not have any references from its stack or heap back to the fun, and dynamic code loading will not be a problem. But somehow, this general warning against funs in spawn has achieved myth status, and I really wish that it was not perpetuated like this.

(If you were nutty enough to write a self-recursive fun using a Y combinator, and call spawn on that, I agree that code reloading would not work.)--Richard Carlsson

#29638: Couple of things about section 10.5:

$HOME/.erlang/lib_chan.conf as stated on p179 is $HOME/.erlang_config/lib_chan.conf on my system - this may be an Ubuntu-ism? Also might be useful to move where this file should be to where you actually write the config file - (page 180, not 179).

I also second the comment elsewhere that it should be clearer that lib_chan is not part of the distribution, and that if you are going to take the bare minimum you need lib_md5 as well as the lib_chan* files.

Some brief description of the sort of error messages early on in the book would be useful (maybe as part of chp 5/6?) - they are quite cryptic coming from a different programming background. I.e. it took me a while to spot the undef and figure out that I needed extra libraries because the function wasn't defined.--Roland

#29243: Ok, I found the lib_chan code. The way it was presented to the reader did not make it clear that lib_chan was code that came with the book and needed to be downloaded. Just stating that it is out of stream did not clarify the situation and the first 4+ pages of Appendix D did not clarify the situation.

Please add a note that the code is part of the code for the book and needs to be downloaded as well as the code in the chapter.--Joe Jones

#29238: The sample Makefile does not work as is on Mac OS X.
Here is my version for Mac OS X:
.SUFFIXES: .erl .beam .yrl

.erl.beam:
erlc -W $<

MODS = example1 example1_lid

all: ${MODS:%=%.beam} example1 example1_drv.so

example1: example1.c erl_comm.c example1_driver.c
cc -o $@ $^

example1_drv.so: example1_lid.c example1.c
cc -o $@ -I/usr/local/lib/erlang/usr/include -fno-common -bundle -flat_namespace -undefined suppress $^

clean:
rm example1 example1_drv.so *.beam--Kazuya Sakakihara

#30751: The shared library must be called example1_drv.dll on Windows systems in order for erl_ddll:load_driver to find it. Otherwise you get
** exception exit: {error,could_not_load_driver}
in function example1_lid:start/1
when you call example1_lid:start().
from the Erlang shell.--Bruce Gunderson

#29239: In ports/example1_lid.c, you include erl_driver.h that comes with the sample code package.
But it may fail under some reader's configuration, due to version mismatch (driver_incorrect_version).
It would be better to write #include <erl_driver.h> so that the version installed to the reader's system is used.
--Kazuya Sakakihara

#31745: I spoke too soon (#31742): there is no platform-dependent conversion happening at all. Opening a file with file:open() uses binary mode for read/write, not text mode, also on Windows. If you want to handle CRLF, you have to do it yourself. Not even io:format("~n",[]) to the emulator standard output stream will produce a CRLF on Windows, only LF.--Richard Carlsson

#31742: Last paragraph: the ~n formatting command: the explanation that "~n is smart" is wrong! (Try it on Windows, or just look in the code for io_lib_format.erl.) It always produces a single newline character (ASCII 10), so it is equivalent to using the escape sequence "\n", except that the latter is expanded at compile time.

What really happens (I think) is that when the newline is printed to the output stream, if the stream is open in text mode - which is normally the case if you are writing to it with io:format() - the newline will be converted to the correct sequence for the platform. (This is probably just as a consequence of the Erlang runtime system being implemented in C.) So Erlang, just like C, works on a normalized text format internally, and converts the newlines at the I/O boundaries.--Richard Carlsson

#29973: There's suggestion to use certain kinds of accumulation techniques for tcp fragments. Now the R12B-0 have brought efficient binary accumulation which should be preferred.

I.e. instead of doing
receive_data(Socket, SoFar) ->
receive
{tcp, Socket, Bin} ->
receive_data(Socket, [Bin|SoFar]);
{tcp_closed, Socket} ->
list_to_binary(reverse(SoFar))
end.

or

receive_data(Socket, SoFar) ->
receive
{tcp, Socket, Bin} ->
receive_data(Socket, list_to_binary([Bin,SoFar]));
{tcp_closed, Socket} ->
SoFar
end.

the R12-> preferred way (by Efficiency Guide chapter 4) would be

receive_data(Socket, SoFar) ->
receive
{tcp, Socket, Bin} ->
receive_data(Socket, <<SoFar/binary, Bin/binary>>);
{tcp_closed, Socket} ->
SoFar
end.

--Jani Launonen

#31749: In the UDP client/server example code, the server is parameterized with respect to 'Port', but the client code (both on p. 261 and p. 262) is hard-coded to contact the server on port 4000. This is not very elegant, and furthermore, there is no text that mentions how the "4000" suddenly turned up in the client code.--Richard Carlsson

#29591: In the udp_test.erl server source:
loop(Socket) ->
receive
{udp, Socket, Host, Port, Bin} = Msg ->
The only explanation of the '= Msg' syntax in the book is back on pdf-110, paper-101 in section 'Match Operator in Patterns' of Misc. Short Topics.
1. The first time through the book, I didn't register this, maybe partly because the context was function definitions, further it's time consuming to rediscover that explanation again. I feel it would be helpful in the udp server section to remind the reader of the meaning of this construct, maybe just with a reference or even footnote back to the Match Operator section.
2. It looks like '= Msg' is used in the udp server as a convenience to simplify the io:format log messages, and so may be worth pointing out explicitly as a handy debugging technique.--Garry Bulmer

#29181: In the code for server2.erl, the catch clause uses "_:Why". I didn't understand what that meant at first. The concept of tags is introduced very loosely on page 80 ("internal errors...always have the tag error"). The code example on page 84 shows a catch that catches "_:_" and explains that the tag "throw" is the default, but in my opinion that is not emphasized enough.

I'd like to suggest that the term "tag" be more formally and clearly defined, and also that you quickly re-explain the "_:_" syntax on p. 295 near the code for server2.erl.
--Jim Menard

#31777: You note that qlc:q(LC) only works if LC is a literal list comprehension, and not if LC is a variable, but you do not mention that it is necessary to add a declaration -include_lib("stdlib/include/qlc.hrl") to the file (or what a parse transform is and why the qlc-expressions work at all). Readers who expect normal expression evaluation semantics get confused by this.--Richard Carlsson

#31781: Section 17.2 "Adding and removing data...":
It is frustrating to read about operations like mnesia:write(Row) when there has been no explanation at all how tables are created. Please insert forward references to 17.5 "Table types" and 17.6 "Creating the initial database".
Preferably also give a short explanation about how the Name used when creating the table is implicitly used by mnesia:write(Record), which takes the record tag as the Table name and the first record field as the primary key.--Richard Carlsson

#31987: SInce it's explaining error logger config file it's abit confusing to have "false" to represent something that is "turned on". First I thought it was a typo.
Might need some explanation on why it only gives "error reports" and not "progress reports and so on".

#29021: Could you please mention OTP behaviors not covered by the "OTP Introduction" and "Making a System With OTP" chapters, and where to go for further information? gen_fsm is very useful in certain systems.

--Brian Zhou

#31066: When sasl_error_logger is configured to write to a file, on Windows at least, the directory must exist before sasl is started. Sasl will not create it. When using Msys on Windows , as explained in Appendix B, the syntax of the filename given in the config file must be Windows syntax but using '/' instead of '\'
e.g. "C:/Documents and Settings/joe/error_logs/THELOG".--Bruce Gunderson

#29919: Compiling my_error_handler (with erlc) produced the following warning:
./my_alarm_handler.erl:9: Warning: undefined callback function code_change/3 (behaviour 'gen_event')

Adding a basic implementation (and export) seemed appropriate, considering that code_change is part of the behaviour.

code_change(_OldVsn, N, _Extra) -> {ok, N}.

#31192: The is_prime function uses the Rabin-Miller primality test, but doesn't properly cite it and doesn't note that it is a probablistic test rather than one that gives certain results.
--Aaron D. Ball

#31992: Due to this line in make_prime/1:
N = make_random_int(K),

2 * N - 3 may have more than K digits, which causes this kind of behaviour:
----------------
Generating a 2 digit prime ..
101
----------------
Using the (K-1)th power of 10 should make it work.--Igor R. Sucupira

#31793: 1st bullet point: "TypeVar: A type variable". This is just a special case of the 3rd bullet point: "Type: A type expression". You should remove this point and instead add a point to the definition of TypeExpression in the previous section: "* A type variable TypeVar is a type expression. This is like a variable in and Erlang expression, but represents some type, not some value."--Richard Carlsson

#31794: 2nd bullet point: "TypeVar::Type: A type variable followed by a type. This means that TypeVar has type Type." This is a misunderstanding. The syntax means "Name::TypeVar: The argument name, followed by a type. Here, Name looks just like a variable, but is only for documentation purposes, to make it easy to talk about the different arguments." Also, the 1st bullet point should be removed, as remarked in #31793, and the 3rd point be moved to 1st place. You could change "Type: A type expression" to "Type: A type expression, possibly just a type variable." --Richard Carlsson

#29802: Chapter E.4: it is reloading, not recompilation in itself, which causes processes to call new code. Instead of saying "recompile", say "reload" or "recompile and reload" (and clarify that the shell function c(Module) does both). Calling the compiler directly, e.g. using compile:file(...), or running erlc from an operating system shell, does not cause reloading.--Richard Carlsson