precedence bug with derived instances

[Simon Peyton-Jones]

| (1) In the first section, in:
|=20
|     instance (cx, cx') =3D> Ci (T u1 ... uk) where { d }
|=20
| 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.

| (2) In section D.1, in:
|=20
|     For example, False < _|_ is _|_, even though False is the first
| constructor of the Bool type.
|=20
| change the operator from "<" to "<=3D".  There is no reason to expect
(False <
| _|_) to be True.

Good idea.

| (3) Section D.4 gives the expected rule:
|=20
|     head (readsPrec d (showsPrec d x "")) =3D=3D (x,"")
|=20
| Why should this not be:
|=20
|     readsPrec d (showsPrec d x "") =3D=3D [(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.

| (4) I don't understand this paragraph in section D.4:
|=20
|     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.
|=20
| 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. "

| (5) The next paragraph of section D.4 says:
|=20
|     Spaces and parentheses are only added where needed, ignoring
| associativity.
|=20
| 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.

| (6) In the bullet that begins "The derived Read instance allows",
change
| "parenthese" to "parentheses".

Thanks

Simon