MEAP 11/02/2010
Third paragraph:

Orig:
"Because we haven’t specified anything on the left side of the arrow, it means that the function we’re expecting as a parameter doesn’t take any parameter for itself"

This was missleading to me. I also know the () => Unit notation.
e.g.
>val f = (g)=>Unit) => {println("begin f"; g(); println("end f"}
f: (() => Unit) => Unit = <function1>

scala> val h : () => Unit = () => {println("begin h"; println("make side effect"; println("end h"}
h: () => Unit = <function0>

scala> f(h)
begin f
begin h
make side effect
end h
end f

Thus I could specify () on the left side and give "no" parameter to h (well actually it's the only value of type Unit "()" ), which passes the above criteria if () is interpreted as empty parameter list.

My humble suggestion:
Maybe a hint (footnote, box) to not mix call-by-name up with "()=>" because... would avoid this confusion (to me).

Corrected MEAP version
Message was edited by: lutzhank

MEAP 11/02/2010

Cut in reading flow while understanding the example:

End of third paragraph:
orig text: "But if you expect a function parameter that takes two
parameters, like foldLeft, you have to define it as follows:
def foldLeft(initialValue: Int, operator: (Int, Int) => Int)= { ... }"

You write about parameterless methods before this sentence and continue with the example afterwards and don't discuss methods/function literals with more parameters at this point I may suggest to either place a short footnote to the place in the book
where functions/methods with more parameters are discussed or to ommit the orig-text, which would make it easier for me, to follow the breakable example.

------------------------
Corrected MEAP version
Message was edited by: lutzhank

MEAP 11/02/2010

Code below with function name "install" in courier font type above it:

right above Listing 2.1 is the following code/text

"try {
op
} catch { case _ => }
That’s it"

Right above the code is the function name install

This confused me for a few seconds. Why? My thoughts just processed install and the code did not fit to install.

For me it would have been easier to read if after "the install function." I could read
"Listing 2.1 holds the complete code. ..." with the complete implementation including the above try catch.

------------------------
Corrected MEAP version
Message was edited by: lutzhank

Didn't want to open a new thread for page 31:

I think the example is somewhat convoluted, maybe because it's mixing the concepts of closures with first-class functions.

If the goal is to demonstrate closures, it'd be better to have an example which
defines a function which accesses/manipulates variables in its lexical scope.
If the goal is to demonstrate first-class functions and passing functions as parameters, the example is ok, although I'd think an example that computes
something or transforms a list would be clearer since it wouldn't require an
explanation of exceptions.

Nitpick:
paragraph 3: "The special right arrow" would be fine w/o the word "special"

I receive a warning - write Throwable after the colon and the warning will disapear

def breakable(op: => Unit) {
try {
op
} catch { case _ : Throwable => }

}