This is neither for PDF nor for paperback edition. I am reading Kindle
version bought at Amazon.

The code examples are in very small, almost unreadable font size. Can
anything be done about this? Thanks!
---
Yes, they were very tiny. We fixed this in 4ed. Sorry for making you
squint.

Not really errata but a suggestion for the next version:  It would help
if there were flow charts or something similar shown to illustrate how
example programs operate.  Seems like a logical step to diagram how the
problem will be solved before jumping into coding.
---
Good suggestion. Tnx.

Table of contents is correct in the book, but wrong on the errata page. 
Chapter 11, Abstract Members is now Chapter 20 in my copy of the third
edition.

[FIXED.  Thanks.]

These improvement to the Java 8 platform are very exciting ..

should be


These improvements to the Java 8 platform are very exciting ..

FIXED

A compilation of the real errors and their correction would be helpful
and time saving. In the current lists, there are redundant comments or
comments not describing errors. This is confusing.

While it's great that readers can supply errata, it is not entirely clear
when an item is simply one reader's opinion, possibly erroneous itself,
as contrasted with an item that has received some editorial scrutiny. Can
we have some indication of which items have been blessed by the authors
or other qualified people, and which are simply raw input from somebody
like me, who has little knowledge of Scala.

"For example, the function pointers of C and C++ ... Nor do they allow
you to define unnamed function literals."
->
C++ supports lambda-s since C++11, see
https://en.cppreference.com/w/cpp/language/lambda
---
True. We changed this to call out Ruby's mutable strings instead in 4ed.
Tnx.

"If it receives a GetChecksum message, it calculates a checksum from the
current value of sum and sends the result back to the requester using the
message send requester ! sum."

SHOULD BE

"If it receives a GetChecksum message, it calculates a checksum from the
current value of sum and sends the result back to the requester using the
message send requester ! checksum."

FIXED in 3ed 4th printing

... and sends the result back to the requester using the message send
requester ! sum ...
The code example uses "requester ! checksum" instead of "sum".


Martin Odersky; Lex Spoon; Bill Venners. Programming in Scala, Third
Edition (1620) (Kindle Locations 388-390). Artima Press.

Fixed in 3ed 4th printing

First paragraph after code sample says that "and sends the result back to
the requester using the message send requester ! sum". 

I think "requester ! sum" is typo here and it should be "requester !
checksum", since this case matches with GetCheckSum it would be better to
send checksum instead of sum.

FIXED in 3ed 4th printing

"This is how the designer of Akka's actors API enabled you to use
expressions such as requester ! sum shown in the previous example: `!' is
a method of the Actor class."

should be

"This is how the designer of Akka's actors API enabled you to use
expressions such as requester ! checksum shown in the previous example:
`!' is a method of the Actor class."

FIXED in 3ed 4th printing

For instance, Lisp, Haskell, and Pythonimplement big
integers; Fortran and Python implement complex numbers.
->
For instance, Lisp, Haskell, and Python implement big
integers; Fortran and Python implement complex numbers.

Note: This seems to be fixed already in 3ed.

In Table 3.1 Some List methods and usages, the List method

thrill.sort((s,t) =>
  s.charAt(0).toLower <
    t.charAt(0).toLower)

might need to be corrected to

thrill.sortWith((s,t) =>
  s.charAt(0).toLower <
    t.charAt(0).toLower)

Sincerely

FIXED in 3ed 4th printing

sort method is depreciated for List type  in version 2.8 and cut off in
later versions and instead sortWith can be used. Sort is mentioned in
table 3.1.

FIXED in 3ed 4th printing

(I am reading the book in Amazon Kindle.)
in Table 3.1,

"thrill.sort" is not working.
I think it is a typo of "thrill.sortWith"

FIXED in 3ed 4th printing

thrill.sort((s, t) =>  s.charAt(0).toLower <  t.charAt(0).toLower)

does not compile. An alternative would be

thrill.sortWith((s, t) => s.charAt(0).toLower < t.charAt(0).toLower)

or even more precise

thrill.sortWith((s, t) => s(0).toLower < t(0).toLower)

FIXED in 3ed 4th printing

(Note: i'm using the safari online version)

In Step 8 at the end of the table:
thrill.sort((s, t) =>  s.charAt(0).toLower <  t.charAt(0).toLower)

Should be:
thrill.sortWith((s, t) =>  s.charAt(0).toLower <  t.charAt(0).toLower)

FIXED in 3ed 4th printing

"In the first line of Listing 3.6 you import the mutable Set."

Actually you import the package scala.collection.mutable.

"As a result, when you say Set on the third
line, the compiler knows you mean scala.collection.mutable.Set."

The third line doesn't say 'Set', it says 'mutable.Set'.

Same problem shows up with Map example later.

FIXED in 3ed 4th printing.

It is written,
"Another useful collection class in Scala is Map."
While in Scala api, Map is mentioned as a trait with a companion object.

FIXED in 3ed 4th printing

Table 5.1 - Some basic types
Basic type Range
Byte 8-bit signed two's complement integer (-27 to 27 - 1, inclusive)
Short 16-bit signed two's complement integer (-215 to 215 - 1, inclusive)
Int 32-bit signed two's complement integer (-231 to 231 - 1, inclusive)
Long 64-bit signed two's complement integer (-263 to 263 - 1, inclusive)
Char 16-bit unsigned Unicode character (0 to 216 - 1, inclusive)

-27 to 27 - 1 should be -2^7 to 2^7 -1, the other errors are the same.

NOTE: This is fine in the PDF, so perhaps this is a problem in the MOBI
or EPUB versions.

Table 5.3 Operator precedence
The order of "= !" and "< >" should be inverted with respect to the
language specification (cf.
https://www.scala-lang.org/files/archive/spec/2.12/06-expressions.html#inf
ix-operations).
Testing seems to confirm the language specification is correct.
---
Wow that's a good one. Fixed in 5ed. Tnx.

gcdLoop (Listing 7.2) calculates gcd correctly for positiv numbers, while
give unreliable results for others.

scala> def gcdLoop(x: Long, y: Long): Long = {
     | var a = x
     | var b = y
     | while (a != 0) {
     | val temp = a
     | a = b % a
     | b = temp
     | }
     | b
     | }
gcdLoop: (x: Long, y: Long)Long

scala> gcdLoop(3,-7)
res1: Long = -1

scala> gcdLoop(-3,-6)
res2: Long = -3

scala> gcdLoop(0,0)
res3: Long = 0

Note: gcd must always be positive and has no meaning for (0,0).

See also: http://www.artima.com/forums/flat.jsp?forum=282&thread=388491

the greet function is:
  def greet() = { println("hi") }

the text says "Because no equals sign precedes its body, greet is defined
to be a procedure with a result type of Unit."  this statement doesn't
appear to describe the definition of greet correctly as there is clearly
an equals sign preceding the body of greet.  since the code is using
function syntax, and not procedure syntax, greet's return type is
inferred from the last expression in the body, which happens to be Unit. 


further, isn't the "procedure" syntax described in the text discouraged
at this point?

FIXED in 3ed 4th printing

scala> def greet() = { println("hi") }
greet: ()Unit

...

Because no equals sign precedes its body, greet is defined to be a proce-
dure with a result type of Unit .

?

There is an equal sign which precedes its body, I suppose the reason it's
()Unit is because println returns ()Unit.

FIXED in 3ed 4th printing

http://i.imgur.com/MBwApXw.png

FIXED in 3ed 4th printing

It reads,

"Because no equals sign precedes its body, greet is defined to be a
procedure with a result type of Unit."

while in the example given just above, greet is defined with `=' thus:
def greet() = { println("hi") }

this was not there in the 2nd edition.

FIXED in 3ed 4th printing

7.2 WHILE LOOPS
In the example annotated with "Because no equals sign precedes its body,
greet is defined to be a procedure with a result type of Unit.", the
equal sign precedes the method body - 'def greet() = { println("hi") }'

FIXED in 3ed 45th printing

In middle of page: "Because no equals sign precedes its body, greet is
defined to be a procedure with a result type of Unit"

Actually the code snippet includes the equals sign. Maybe since procedure
syntax is deprecated, snippet was updated, but text wasn't changed to
reflect this?

FIXED in 4th printing

For each of these it gen-
erates an Iterator[String] , the result of the fileLines method, whose
definition is shown in Listing 7.8. An Iterator offers methods next and
hasNext that allow you to iterate over a collection of elements. This
ini-
tial iterator is transformed into another Iterator[String] containing
only
trimmed lines that include the substring "for" .

^^^

In the Listing 7.8 the result of fileLines is List[String], not
Iterator[String] (scala.io.Source.fromFile(file).getLines().toList). 

Besides, even if it was Iterator[String] `for` comprehension expands to
flatMap/map, not to next & hasNext. So mentioning next and hasNext in
this context is probably misleading?

FIXED in 3ed 4th printing

It is written,

"For each of these it generates an Iterator[String], the result of the
fileLines method" while the fileLines method actually results in a
List[String] due to the last ".toList" function as defined in Listing
7.8:

"def fileLines(file: java.io.File) =
scala.io.Source.fromFile(file).getLines().toList"

FIXED in 3ed 4th printing. Changed toList to toArray and updated text.

Foot note says
Although you must always surround the case statements of a catch clause
in paren- theses, try and finally do not require parentheses if they
contain only one expression. For example, you could write: try t() catch
{ case e: Exception => ... } finally f().

shouldn't parentheses be replaced by curly braces

FIXED in 3ed 4th printing

In the last sentence of the second paragraph in section 8.2, I believe
"... to delete the helper functions if you later rewrite the class a
different way" should be "... to delete the helper functions if you later
rewrite the class *in* a different way".

FIXED in 3ed 4th printing

It's written "You can just use the parameters of the outer processLine
function, as shown in Listing 8.2."

The outer function is processFile, not processLine

FIXED in 3ed 4th printing

Sidebar mentions "println(drop)", should probably be something like
"println(list.drop)"

FIXED in 4th printing

It is written - "This relationship is called composition because class
ArrayElement is “composed” out of class Array[String],"

I think, it's technically not thorough to call 'Array[String]' a 'class'
when actually it is a 'type' made by passing type 'String' the class
'Array'

;/

FIXED in 3ed 4th printing.

Text talks about matching constructor pattern UnOp("-", e), with "... and
whose second argument matches e". Since e is being introduced here, it
seems misleading to talk of any argument matching e (as if this could
fail.) It'd be better to state something like that anything at that
position in the expression is considered a match, and e is bound to that
part of the expression.

FIXED in 4th printing

In the last line in last paragraph under "Protected Members" it says
"because Other is in the same package as 'Sub'". It should have been
"because Other is in the same package as 'Super'"
---
Correct. Fixed in 5ed. Tnx.

An ex-
ample of the latter is the react example given above, where the argument
is a partially defined function, defined precisely for those messages
that the
caller wants to handle.

^^^

There is no "react" example above, there is "receive" method though.

FIXED in 3ed 4th printing

The text mentions "the react example given above".  However, there is no
"react example".  I'm guessing you mean to say "receive example" or "Akka
actor example".

FIXED in 3ed 4th printing.

Following the sequence of code in the book, when I enter:
val immu = Map.empty ++ muta

the response is:
immu: scala.collection.mutable.Map[String,Int] = Map(ii -> 2, i -> 1)

In order to get an immutable Map, I need to make the following changes:
import scala.collection.immutable
val immu = immutable.Map.empty ++ muta
---
Good point. Will add something to clarify need to restart the REPL after
that import of scala.collection.mutable.Map. Tnx.

The reason this works is that since printBookList ’s pa-
rameter type is Book , the body of the printBookList method will only be
allowed to pass a Book into the function.

^^^
printBookList is a method and it doesn't have type parameters, what was
probably meant is that "val books: Set[Book]"'s parameter type is Book,
hence "book" in "info(book)" has a type Book.

FIXED in 3ed 4th printing

The problem reported about p.438 in 2nd edition regarding "bessy eat (new
Grass)" (see
https://booksites.artima.com/programming_in_scala_2ed/errata?c=20 ) is
still found in 3rd edition. I am reading the book on safari.oreilly.com
and hence page number may not be 418 but it's definitely 3rd edition.

[Text from previous report:

It makes sense that I cannot feed the Cow 'bessy' a new Fish, but I
cannot feed bessy new Grass either.  From the text it seems that I should
be able to.  Why else point out that bessy cannot eat Fish if it can't
eat Grass either?

scala> class Food
defined class Food

scala> abstract class Animal {
     | type SuitableFood <: Food
     | def eat(food: SuitableFood)
     | }
defined class Animal

scala> class Grass extends Food
defined class Grass

scala> class Cow extends Animal {
     | type SuitableFood = Grass
     | override def eat(food: Grass) {}
     | }
defined class Cow

scala> class Fish extends Food
defined class Fish

scala> val bessy: Animal = new Cow
bessy: Animal = Cow@4bd767

scala> bessy eat (new Fish)
<console>:12: error: type mismatch;
 found   : Fish
 required: bessy.SuitableFood
       bessy eat (new Fish)
                  ^

scala> bessy eat (new Grass)
<console>:11: error: type mismatch;
 found   : Grass
 required: bessy.SuitableFood
       bessy eat (new Grass)
                  ^
]

Terrible mistakes!  Two BuggyAnimals came out of nowhere!
---
True! This mistake has been fixed in 5ed. The animals are still buggy in
the same way, but you no longer see a source file name.

"The toString method in class Currency..."  should be "The toString
method in class CurrencyZone..."

"To achieve this, you could implement Currency's..."  should be "To
achieve this, you could implement CurrencyZone's..."
---
Fixed in 5ed. The correct class name is actually AbstractCurrency.

"...method, from, to class Currency..."  should be "...method, from, to
class AbstractCurrency..."

I guess those that I mentioned for page 438 should also be
AbstractCurrency instead of CurrencyZone.
---
Fixed in 5ed. Tnx!

Section 21.2
Chapter 21 · Implicit Conversions and Parameters

Duplication of world "some" in first new paragraph on page 477.
---
Fixed in 5ed for sure, possibly 4ed or even 3ed. But fixed. Tnx.

Looks like Val CurrencyUnit: Currency at the bottom of the listing was an
after-thought to add, when it wouldn't compile without it.  Works just as
good if it is placed by the top with the other CurrencyZone declarations.
---
I suppose so. Does look kind of funny. And it looks maybe even worse in
indentation style in Scala 3 if there's no end. I made a TODO to rework
this. Going to add an end, but may move that up, which is what I'd
probably do in my own source code. Come to think of it, this *is* my own
source code!

Email extractor accepts strings like "John@epfl.ch@" as a valid email
address

scala> EMail.unapply("John@epfl.ch@")
res78: Option[(String, String)] = Some((John,epfl.ch))

which is unexpected and likely incorrect. 
As well it looks inconsistent with a treatment of "@John@epfl.ch" as
non-email

scala> EMail.unapply("@John@epfl.ch")
res80: Option[(String, String)] = None

Note: This is a good point, but too much for fixing in a reprint. Will
look at this for the 4th edition.

"In this section, we illustrated some some of the power of implicit
conversions..."

might be

"In this section, we illustrated some of the power of implicit
conversions..."

There are two 'some's.

Perhaps the package of the following code example should be changed to
"mutable":

package scala.collection.immutable
final class ListBuffer[T] extends Buffer[T] {
  private var start: List[T] = Nil
  private var last0: ::[T] = _
  private var exported: Boolean = false
  ...

FIXED

"What’s more, collections are have been adapted to parallel execution on
multi-cores."

should be

"What’s more, collections have been adapted to parallel execution on
multi-cores."

FIXED in 3ed 4th printing

In the "Fast: ..." paragraph, the fourth paragraph says "... collections
are have been adapted ..."

FIXED in 3ed 4th printing

"Copies at most len elements of arr, starting at index s. The last two
arguments are optional."

should be

"Copies at most len elements of the collection to arr, starting at
index s. The last two arguments are optional."

FIXED in 3ed 4th printing.

In the entry for zipWithIndex, "indicies" should be "indices".

FIXED in 3ed 4th printing.

Text says Seq, Set, and Map all implement PartialFunction trait, but it
appears that Set does not actually implement PartialFunction.

FIXED in 4th printing

In the entry for lengthCompare, "xs.lengthCompare ys" should be "xs
lengthCompare i". Additionally, the description is wrong (at least for
modern versions of Scala) because "i" must be an Int, not a Seq. The text
should say something like:

"Returns -1 if the length of xs is less than i , +1 if it is greater, and
0 if they are equal. Works even if xs is infinite."

FIXED in 3ed 4th printing. Not sure how that one got through. I looked
back in time and as of 2.7 lengthCompare took an Int.

The syntax of "xs.lengthCompare ys" is NOT legal.

Follow the style of the given table in that page, this line should be
"xs lengthCompare ys".

FIXED in 3ed 4th printing

The second line after section title.

"Scala’s Predef class offers an implicit conversion that lets you"

Predef is an object, NOT a class.

FIXED in 3ed 4th printing.

The operations on sequences, summarized in Figure 24.3, ...

Should be:

The operations on sequences, summarized in Table 24.3, ...

---
Fixed in 5ed. Tnx.

In discussion of getOrElseUpdate:  "... but it would have have taken ..."

FIXED in 4th printing

Last sentence of first paragraph reads:

You could also have implemented cachedF directly, using just basic map
operations, but it would have have taken more code to do so:

The word 'have' is duplicated and therefore the sentence should read:

You could also have implemented cachedF directly, using just basic map
operations, but it would have taken more code to do so:

FIXED in 3ed 4th printing

In discussion of weak hash maps:  "... unreachable, it's entry is removed
..."

FIXED in 4th printing

In table 24.9, the description for putIfAbsent should be "Adds key/value
binding k -> v unless k is already defined in m".

FIXED in 3ed 4th printing

In the first line, "One the one hand" should be "On the one hand".

Later in the same paragraph, "Scala arrays offer much more their Java
analogues" is missing a "than".

FIXED both in 3ed 4th printing

and a pop on a stack is the same a tail on a list  should be:
and a pop on a stack is the same as a tail on a list
---
Fixed in 4ed or 5ed.

The book shows:
scala> val vv = v.view
vv: scala.collection.SeqView[Int,Vector[Int]] = 
SeqView(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

But I get:
scala> val vv = v.view
vv: scala.collection.SeqView[Int,scala.collection.immutable.Vector[Int]]
= SeqView(...)
---
Fixed in 4ed.

it sameElements jt -- text (and Scala doc website) says at least one of
the iterators will be at its end after this operation. But if a
difference is found, the iterators will be positioned immediately after
the difference, not necessarily at the end.

FIXED in 4th printing

"Internally, these conversion work" should be "Internally, these
conversions work".

FIXED in 3ed 4th printing

As I stated in a previous submission, it.next() in the sequence of code
on this page produces:

scala> it.next()
res29: String = of

Upon reviewing the API, I see the reason is because after using
dropWhile:

Reuse:  ...Using the old iterator is undefined...

Thus to return "number" would need to do:

scala> val it = Iterator("a", "number", "of", "words")
it: Iterator[String] = non-empty iterator

scala> val iter = it dropWhile (_.length < 2)
iter: Iterator[String] = non-empty iterator

scala> iter.next()
res28: String = number
---
Fixed in 5ed. Tnx.

The book says:
scala> it.next()
res5: java.lang.String = number

But I get the following:
scala> val it = Iterator("a", "number", "of", "words")
it: Iterator[String] = non-empty iterator

scala> it dropWhile (_.length < 2)
res10: Iterator[String] = non-empty iterator

scala> it.next()
res11: String = of

The size method shows the following after the dropWhile:
val it = Iterator("a", "number", "of", "words")
it: Iterator[String] = non-empty iterator

scala> it dropWhile (_.length < 2)
res14: Iterator[String] = non-empty iterator

scala> it.size
res15: Int = 2

So, for some reason it also dropped "number" or the next method skips the
present "number" string.

(Using scala 2.12.4)
----
Yes, fixed in 5ed. Tnx.

Not exactly an errata, but...
book talks about JavaConversions and omits any mention of JavaConverters.
Explicit JavaConverters seem to be preferred over implicit
JavaConversions nowadays, so it seems a glaring omission to not mention
JavaConverters here.

---
Fixed in 4ed.

Where the text says:

   ... you need to define two apply methods in the CanBuildFrom trait

it should probably say something like:

   ... you need to define two apply method from the CanBuildFrom
   trait

or:

   ... you need to define two apply methods declared in the
   CanBuildFrom trait.

(The current wording sounds like it's saying that one needs to put
something in the CanBuildFrom trait.)

FIXED in 3ed 4th printing

In footnote:  "Java Persistence Architecture, , for example,"

FIXED in 3ed 4th printing

Reference to Chapter ?? in Volatile Fields section. Also, the text about
giving "different guarantees on different platforms" might be outdated,
if Scala is only targeting the JVM nowadays.

FIXED in 3ed 4th edition

In section on Volatile fields it states: "See Chapter ??" for details,
instead of supplying a chapter number.

Fixed in 3ed 4th printing

There is a chapter reference that has not been set in chapter 27, page
616, line 3 in section "Volatile fields".

"See Chapter ?? for the details."

FIXED in 3ed 4th printing.

At the last sentence of the first paragraph, the numbering by LaTex
should be corrected:

    "See Chapter ?? for the detail."

I think that you gave a wrong reference name.

FIXED in 3ed 4th printing.

See Chapter ?? for the details.

See page 7 of Chapter 1 for a glimpse of actors or for more details see
Chapter 30 of the first edition of this book, or Chapter 32 of the second
edition.

FIXED in 3ed 4th printing

line 3 - "see chapter ?? for details"

Please refer the chapter instead of two question marks

FIXED in 3ed 4th printing

Section 29.1, end of 3rd paragraph: 
This wiring task can by thought of..."

should be

"This wiring task can be thought of..."

FIXED in 3ed 4th printing.

In middle of page: perform asssertions

FIXED in 3ed 4th printing

import scala.util.parsing.combinator._

object parsing is not a member of package util
http://stackoverflow.com/questions/26691750/using-util-parsing-in-scala-2-
11

obviously need to add a dependency since scala 2.11

TODO

The last paragraph refers to "the close button on the upper right."  

That location depends on the operating system and the window manager, so
probably it should say something like "the close button in the window's
title bar" (which, although not true for _all_ window manager setups is
more general than the current text).

TODO

Hi,

The SCells example in last chapter does not compile. After performing
following changes:
1. Class Cell:
from:
case class Cell(row: Int, column: Int) extends Publisher
to:
case class Cell(row: Int, column: Int) extends Component with Publisher
2. Class Cell - method value_=:
from:
publish(ValueChanged(this))
to:
publish(new ValueChanged(this))
3. Class Spreadsheet - reactions:
from:
case ValueChanged(cell) => updateCell(cell.row, cell.column)
to:
case ValueChanged(cell) => cell match {
  case c: Cell => updateCell(c.row, c.column)
}

code compiles and application behaves as expected.


Regards