This book should not have been published in its current form. It contains many instances of incorrect and inconsistent terminology, as well as many other errors.
This page is work in progress. I have not read the entire book yet, and I have not yet entered all the remarks I have to the parts that I have read. I will work on this page incrementally.
Page 34. "the presence of a decimal point determines whether you number is seen as a floating-point number or an integer". This statement is wrong. The sequence of characters 234. is read as an integer despite having a decimal point in it, and the sequence of characters 1d0 is read as a floating-point number despite not having a decimal point in it.
Page 35. "Common Lisp uses two modes when it reads your code: a code mode and a data mode". This statement is wrong. When the code is read, the reader does not distinguish between code and data. This distinction is determined later.
Page 36. "Lisp will expect Lisp code to be entered as a list". This statement is wrong. Numbers and strings are perfectly good instances of Lisp code, and they are not entered as lists.
Page 36. "the commands you enter need to be structured as forms". Common Lisp does not have the concept of a "command". It is not commands structured as forms that are entered, but just forms. The term "command" is used in many places in the book, often in inconsistent ways.
Page 36. "A form is simply a list with a special command at the beginning". First of all, this statement is false. Not all forms are compound forms. Second, now the first element of a command is another command? So not only does Common Lisp not have the concept of a "command", but this concept is used in an inconsistent way, and in fact makes it impossible to respect because of the infinite recursion.
Page 36. "When reading a form, Lisp sends all the other items in the list to the function as parameters". First of all, no sending is done when Lisp reads the form. It is done when the form is evaluated. Second, the term "parameter" is used the wrong way and should be "arguments" instead. Parameters are what is found in lambda lists, not in function-call forms.
Page 36. "This form is then executed". The correct terminology is "evaluated". The term "executed" is used in many other places in the book.
Page 37. "To treat the subsequent form as a chunk of data". If it is treated as data, then it is not a "form".
Page 38. "For instance, suppose we create the list '(1 2 3). Here's how this list is represented in computer memory:" This phrase is followed by a drawing that shows three cons cells representing the list (1 2 3). But that was not the list that was created. It was '(1 2 3) which is the same as (quote (1 2 3)) so the drawing does not match the list that was created.
Page 39. "(cons 'chicken ())". This use of the empty list is in direct violation of the conventions mentioned in section 1.4.1.4.4 of the Common Lisp standard.
Page 40. "The REPL echoed back to us our entered items as a list, (pork beef chicken), but it could just as easily (though a little less conveniently) have reported back the items exactly as we entered them: (cons 'porc (cons 'beef (cons 'chicken ()))). Either response would have been perfectly correct." This statement is so blatantly incorrect that it should absolutely not be in the book. If the evaluator had given that "response", it would have been a very bad evaluator indeed.
Page 41. "We know that cdr will take away the first item in a list". That is absolutely not what cdr does.
Page 41. Remember that there is no difference between a list created with the list function, one created by specifying individual cons cells, or one created in data mode using the single quote." This statement is blatantly false. In the last case, the resulting list is a literal, and the consequences are undefined if such a list is subsequently modified. There is no such problem in the first two cases.
Page 42. "The car function gives us the first item in the list... Next, we use the cdr command to ..." So car is a "function", but cdr is a "command"?
Page 51. In the expression "(if list ...)" the use of a value that is not meant to be a Boolean, in this case list, is not recommended. Se page 13 of the "LUV slides" by highly experienced developers Peter Norvig and Kent Pitman.
Page 53. The book mentions "the if command", but if is not a "command", since common Lisp does not have any commands. Instead if is a "special operator", and a compound form with if in its car is a "special form". Later, on the same page, it mentions "if statement", but the correct term is "form".
Page 53. "Usually, when a function is executed in Lisp, all the expression after the function name are evaluated, before the function itself is evaluated." Again the terminology is wrong. The function is not "evaluated"; it is "called". It would be better written as "In a function-call form, all the expressions after the function name are evaluated, before the function is called."
Page 53. In the description of the semantics of if the word "parameter" is used where "argument" is meant.
Page 53. In the description of the semantics of if the word "condition" is used where "conditional" is meant.
Page 53. The term "conditional command" is used, but there is no such thing in Common Lisp.
Page 54. "Since only one expression inside an if is ever evaluated...". This is wrong. Both the conditional expression and one of the other expressions (if there are three arguments) are evaluated.