based upon final version PDF created 7/6/2010 11:44:27 1. I.E. and e.g. should be followed by commas -- unless UK usage differs from US standards. (Page 3 and elsewhere, although FFI chapter seems to have the commas.) Also, inconsistent mix of British and American usage throughout (-ize and -ise, flavour, behaviour, behavior, analyse, color, colour, finaliser, finalizer, etc.) 2. Inconsistent spelling (lowercase/uppercase in section 1.4; lower-case/upper-case in section 2.4) 3. In section 3.11, boolean misspelled boolen. 4. LaTeX macros involving @ showing up in text. See sects 3.12, 6.4.2, 11.1, and in Chapter 9. 5. In section 3.15.2, reference to third bullet seems like it should be fourth bullet. 6. In section 3.17.2, the example that is supposed to return [undefined,undefined,undefined] seems like it really ought to return undefined, although I can see in the description above for ~apat matching where the other interpretation would hold. I actually tried this in GHC 10.4.2, binding the result to a variable and then applying the function length to it, and it comes back with undefined, whereas performing "length [undefined,undefined,undefined]" returns 3. So it appears that in this case, at least GHC 10.4.2 is returning undefined rather than [undefined,undefined,undefined]. 7. In section 6.3.4, "[LT..]" needs whitespace in the middle to parse correctly. 8. I'm curious about last part of section 6.4.3 that says 0**y is undefined. It seems to work reasonably under GHC, returning 0 in every case except 0**0, which returns 1 (the ^0 == 1 rule taking precedence, apparently.) Saying 0**0 is undefined seems reasonable, but why 0**y? 9. In section 6.4.6, statement about b^(d-1) <= m < b^d doesn't seem to hold when m < 0. Should it be |m| in the equation, rather than m? 10. Section 7.1 uses "function" in places where it ought to use "action". It seems more correct to describe print as returning an action that outputs a value. Most of the "Input Functions" (e.g., getChar, getLine, getContents, readLn) should be described as actions, not functions. It switches to using the term "operation", which seems better, but then reverts back to "function". 11. In section 8.4, variable misspelled varibale. 12. In section 8.5.1, in "we require that chname ends on .h", "on" should be "in". 13. Also in section 8.5.1, dependent misspelled "dependant". 14. Last paragraph of section 8.5,1 has extra "a" -- "... defined to a accept a ...". Following sentence has a semicolon where it should have a comma. 15. In section 10.3, "(i.e. the programmer..." has no closing paren. 16. In section 10.4, "... other lines are comment", "comments" sounds better. This occurs twice. 17. Also in section 10.6, anything misspelled "anyything". 18. In Chapter 15, it would be more clear to describe "bit i" as producing a value with the ith bit set, and all other bits clear. 19. In section 20.3.1, caveats about finiteness of lists similar to ones given for "and" and "or" could also apply to "any" and "all". Ditto for elem, notElem, etc. Maybe a single paragraph could summarize this short-circuiting behavior for all of them. 20. In heading for 20.9.2, quotes around "Set" are not balanced. Both are closing quotes. Ditto for 20.10.1, 20.10.2. 21. In section 29.1.1, "finaliser" and "finalizer" used in same paragraph. 22. In section 38.2, first occurrence of 'dual' has mismatched quotes. 23. In section 41.1, quotes around "perform" are mismatched. Word "function" is mildly misused again here. 24. In section 41.3.1, it would be nice to document what happens if act terminates abnormally, and then a secondary exception occurs during the closing of the handle. Oftentimes systems lose the primary exception and propagate out the secondary exception, whereas in reality we may be more interested in the original primary exception. 25. In section 41.4.4, bullet before isPermissionError isn't rendered correctly. Alex