[Haskell-cafe] Comments on Haskell 2010 Report

[Alex Stangl]

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