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