precedence bug with derived instances

[Dean Herington]

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