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