Errata for Seven Languages in Seven Weeks

#50089: You list the "logical operators" | and & as behaving more or less like || and && but without shortcutting.

This is incorrect. | and & are the bitwise operators and the only reason they can behave somewhat like || and && in some circumstances is due to the specific types you have been comparing and how they have these operators implemented.

It is misleading not to specifically refer to these as the bitwise operators.--Oliver Hookins

#49405: The attr keyword defines an instance variable. Several versions exist. The most common are attr (defining an instance variable and a method of the same name to access it)…

Presumably this should be attr_reader rather than attr?--Vincent Bray

#49230: In section "Classes in Scala": class Person(firstName: String, lastName: String) doesn't result in a class with firstName and lastName attributes, as the text says. It merely results in a class whose constructor takes two arguments but doesn't do anything with them.

To get attributes, "val" must be added in from of the two parameters. Otherwise readers will be confused that they cannot access the supposed attributes if they experiment with the example:

scala> class Person(firstName: String, lastName: String)
defined class Person

scala> val gump = new Person("Forrest", "Gump")
gump: Person = Person@43900f17

scala> gump.firstName
<console>:10: error: value firstName is not a member of Person
gump.firstName
^

with val though:

scala> class Person(val firstName: String, val lastName: String)
defined class Person

scala> val gump = new Person("Forrest", "Gump")
gump: Person = Person@707cdc58

scala> gump.firstName
res1: String = Forrest--Robin

#48929: In the description of the sort example it is said "that will yield a case-insensitive sort".
This is not true as the comparison is only performed on the first character of each word--Norbert Müller

#49449: 4 + "string".
"Unlike Scala, there's no coercion between strings and ints."

Yes, but the example is misleading since + doesn't concatenate strings, e.g.
"4" + "string".
yields the same exception.--Jerry Morrison

#49450: {comic_strip, {name, "Calvin and Hobbes"}, {character, "Spaceman Spiff"}}.
"We've represented a hash for a comic strip."
...
"If you are used to Ruby or Java-style hashes, it may seem strange to have the initial atom ..."

The code shows a way to represent key-value associations but I don't think there's any hashing going on here. The order of key-value pairs matters and a key may appear multiple times. Can it look up values by key?

The initial atom is a simple way to indicate type information (what Scala does with case classes) and indeed it doesn't fit the hash table concept.--Jerry Morrison

#50403: Clojure: Under the Booleans and Expressions section, you give an example of
(= 1 1.0)
and in the example, it evaluates to true. When I run the example on my machine, it evaluates to false. --Brad Cantin

#49000: In "you’ll define a higher-order function with the fn function", "higher-order" should be "anonymous". Using "fn" always defines an anonymous function which may or may not be higher order. Higher-order function may also be defined using "defn". In fact your example using fn is not higher-order.--art gittleman

#49643: Section: Infinite Sequences and take

Perhaps it's a language change in Clojure 1.3, but the fib-pair example as written gets an ArithmeticException integer overflow. Starting iterate with [1N 1N] gets it to happily use BigInt values.

BTW there's no need to map first over all the iterated values -- it's enough to take the first of the nth pair -- but maybe you wrote it that way to demonstrate that map works on infinite sequences.

Is it typical Clojure code to compute one more fibonacci number than needed vs. returning the second element of the previous fib-pair?--Jerry Morrison

#50849: This page says:

"[...] if/then/else statement"

and later:

"In Haskell, if is a function"

Both are wrong -- 'if/then/else' is an expression with special syntactic support. --Matt Fenwick

#50850: "[...] use the let function [...]"

let is not a function.

"in Haskell, let binds a variable to a function"

'function' should be replaced by 'value', as is shown in the following example.--Matt Fenwick

#48967: There is a discrepancy between the two implementations of the Fibonacci sequence on pages 262-263 of the UK edition.

The 1st fib implementation prints out the nth Fibonacci number like a zero based array (write out the 1st 10 numbers starting with a 0). For example fib 10 returns 89, which is the 11th Fibonacci number. The 'x' in the fibTuple is the correct fibonacci number though.--Tom Kealy

#50851: "Haskell includes first-class ranges and some syntactic sugar to support them"

Ranges are not first-class, they're just sugar for calls to functions from the Enum typeclass.--Matt Fenwick

#51522: Two issues [page 276-277]
The composition operator [pg276] is misused; "foo(bar x)" would be "(foo . bar) x". "(foo x).(bar x)" can be written "(foo <*> bar) x" using applicatives, but that goes beyond the scope of the section.

Second, the starter 'monad' example [pg277] is also applicitive functor-ish rather than monad-ish. '>>==' and 'rtn' are typed 'Position a -> Position a'; to be monadic they must be type 'a -> Position a'

Evaluation in a 'do' block is enforced by composition, but it is not the same as stringing functions together with the compose operator; if "(bar . foo) x" is valid for a monadic x, then the equivalent bind would be "return x >>= foo . return >>= bar . return".--Ryan Domigan

#49417: Instead of
"foldl1 (+) 0 [1 .. 3]"
it should either read
"foldl (+) 0 [1 .. 3]"
or
"foldl1 (+) [1 .. 3]"

Anyway, it might be a good idea to shortly discuss the difference between foldr/foldl and foldr1/foldl1 or leave out the latter version. IMO this difference is not related to the application of an operator, e.g. (+), in contrast to an anonymous function.--Kay-Uwe Kirstein

#50858: "Haskell allows us to chain let expressions together and express the final form in an in statement."

The example doesn't show chained let expressions -- it shows a single let expression.

There is no such thing as an 'in statement'. That is part of the syntax of let expressions.--Matt Fenwick

#50861: "return wraps up a function into a monad"

'return :: Monad m => a -> m a'. It injects any value, not just functions, into the monad.

">>= unwraps a function"

Same thing.--Matt Fenwick

#50862: Just is not a type. It is a function of type ':: a -> Maybe a'.

The examples at the top of the page are confusing. They should probably be:

Prelude> Just "some string" :: Maybe String
...
Prelude> Nothing :: Maybe String
...

This shows that there can either be a value or not. However, "Just Nothing" is of a totally different type than 'Just "some string"'.

"The bind is also easy. For Nothing, it returns a function returning Nothing. For Just x, it returns a function returning x."

The Maybe implementation of >>= does not return a function.--Matt Fenwick

#50863: "The fully polymorphic template system"

The type system is not a template system. Although there is something separate and unrelated called Template Haskell.--Matt Fenwick