Patrik Jansson patrikj@cs.chalmers.se
Mon, 18 Jun 2001 10:48:04 +0200 (MET DST)

```In short: change the eq. for readsPrec in appendix D.4

In detail:

From "The Haskell 98 Report: Derived Instances: D.4"

...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty. It
should be the case that

That is, readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...

Note that the equation stated is not true unless the string r starts with
some token-ending combination.

Counter-examples:

> testreadshow :: (Show a, Read a) => a -> String -> a

A simple one that just fails: the problem is that "Nothingx" can't be
parsed.

> test1 = bad1 == Nothing

Using this we can make the law really false by inventing a datatype
where one constructor is a prefix of another constructor:

Actually there is a predefined type with lots of constructors (Int)
where many values are prefixes of others:

> test3 = bad3 == 1

> main = do print (bad3, test3)

OK, so the falsity of the claim is proved - what could we write instead?

The sentence explaining the equation is correct:

... readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.

Thus a simple way out is to remove the equation and the preceding
sentence leaving the paragraph as:
[Alternative A:]

...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty.
Function readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...

Another simple alternative is to weaken the the equation by replacing
the variable r by the empty string:
[Alternative B:]

...
The function readsPrec d s accepts a precedence level d (a number from
0 to 10) and a string s, and attempts to parse a value from the front
of the string, returning a list of (parsed value, remaining string)
pairs. If there is no successful parse, the returned list is empty. It
should be the case that

That is, readsPrec should be able to parse the string produced by
showsPrec, and should deliver the value that showsPrec started with.
...

[Alternative C:]
A third alternative would be to keep the equation unchanged but to add
the requirement that the string variable r should start with a "token
ending sequence of characters". But what does "token" mean? As an
explanation it might be OK, but the report should be pretty formal and
self-contained so I think this is might be undesirable.

A more complicated alternative would be to state (in words or in
equations) a more detailed correctness requirement, but I think that