Simon Peyton-Jones wrote:
| (1) In the first section, in: | | instance (cx, cx') => Ci (T u1 ... uk) where { d } | | the use of "(cs, cs')" is a bit loose (that is, suggestive rather than | precise syntax). One can't (according to the report, though GHC seems to | allow it) have nested parentheses in a context, which would occur if cx | included parentheses.
True --- but I think it's too late to improve this. I don't think it's misleading enough to matter.
Agreed.
| (2) In section D.1, in: | | For example, False < _|_ is _|_, even though False is the first | constructor of the Bool type. | | change the operator from "<" to "<=". There is no reason to expect (False < | _|_) to be True.
Good idea.
| (3) Section D.4 gives the expected rule: | | head (readsPrec d (showsPrec d x "")) == (x,"") | | Why should this not be: | | readsPrec d (showsPrec d x "") == [(x,"")]
I can't think why not, unless there is a shorter valid parse, which I suppose is conceivable. I'd rather not change this.
In fact, neither rule above is true for the example given in section D.5. To see this, run the following program: infix 5 :^: data Tree a = Leaf a | Tree a :^: Tree a deriving (Eq, Ord, Read, Show) main = mapM_ trial [0..10] where trial d = print (readsPrec d (showsPrec d x "") :: [(Tree Int, String)]) x = Leaf 1 :^: Leaf 2 Perhaps we want: readsPrec should be able to parse the string produced by showsPrec, and should deliver the value that showsPrec started with. That is, the list result of readsPrec d (showsPrec d x "") should contain exactly one pair whose second element is "", and the first element of that pair should be equivalent to x.
| (4) I don't understand this paragraph in section D.4: | | readsPrec will parse any valid representation of the standard types | apart from lists, for which only the bracketed form [...] is accepted. See | Appendix A for full details. | | The statement seems to say that ((readsPrec 5 (show | "abc"))::[([Char],String)]) is invalid, but that can't be what it means to | say.
Sigh. You are right. For strings, only "foo" is acceptable. (GHC accepts the ['f','o','o'] form too, but the Report does not. So I guess the wording should be:
"readsPrec will parse any valid representation of the standard types apart from strings, for which only quoted strings are accepted, and other lists, for which only the bracketed form [...] is accepted. "
That's better.
| (5) The next paragraph of section D.4 says: | | Spaces and parentheses are only added where needed, ignoring | associativity. | | The phrase "only where needed" suggests that (show (1 :$ 2 :$ NT)) should | produce the string "1:$(2:$NT)" (no spaces) rather than the string "1 :$ (2 | :$ NT)", as claimed later in the section (and borne out by GHC). It needs | to be stated that an infix operator is preceded and followed by a space.
Maybe I should remove "spaces and"; this is really only about parens.
That sounds good.
| (6) In the bullet that begins "The derived Read instance allows", change | "parenthese" to "parentheses".
Thanks
Simon
-- Dean