precedence bug with derived instances

[Christian Sievers]

Simon Peyton-Jones wrote:

> I can only make minimal changes now.  I suspect the smallest change is
> to require that
> 	(x,"")  `elem`  readsPrec d (showsPrec d x "")
> 
> This weakens the existing equation by not requiring (x,"") to be the
> first parse returned.
> 
> Dean writes: 
> | 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.
> 
> I don't understand this.  What does "equivalent" mean?  And how does
> this differ from the (incorrect) claim that 
> 
> 	     readsPrec d (showsPrec d x "") == [(x,"")]

That >> whose second element is "" << obviously means to apply
   filter (("" ==) . snd)
to the list.  Using list comprehension, that gives

    [ r | (r,"") <- readsPrec d (showsPrec d x "") ] == [x]

This is nearly what you suggested, with the additional condition that there
may only be one complete parse.  I think this is what we want.

I guess "equivalent" just means equality without suggesting that the type is
an instance of Eq.  There are other places where the report uses == in
situations where you can't really apply it, for example, in D.2 it says
"we would have
        [Orange ..]         ==  [Orange, Yellow, Green]",
which is true, but we can't use this expresion and expect it to reduce to
True, because it is just not type correct.  So I think we should ignore this
problem now.


All the best
Christian Sievers