> > read :: Read a => String -> a
> > read s = let [(r,s')] = reads s in r
> >
> > This *won't compile* if you don't treat the let binding definition
> > monomorphicly. Without monomorphism, the types of r and s' are
> >
> > r :: Read a => a
> > s' :: Read a => String
> >
> > This leads to an ambiguity error for s'.
>
> I'm not buying it (the DMR being responsible for resolving overloading
> ambiguity).
>
> There's nothing ambiguous in that definition, because s' is not used.
> There's nothing even ambiguous about the meaning of s' (we can apply the
> dictionary translation just fine). The problem is with uses of things
> like s'. Haskell takes the stance that you can't declare something you
> can't use (something with a type that would lead to ambiguity in use),
> but I say this example shows us how that stance may well be shortsighted.
What worries me is that a programmer might write this:
read2 :: (Read a, Read b) => String -> (a,b)
read2 2 = let [(r1,s1)] = read s
[(r2,s2)] = read s1
in
(r1,r2)
Here, s1 is indeed used, so the ambiguity problem does bite.
The troubling thing is that "read" works (at least if the MR
is lifted) but "read2" does not.
I am concerned too about the efficiency problem. Suppose that
the ambiguity problem was resolved by choosing some arbitrary
type. (A bad idea, but still.) And suppose that we continued
"read2" so that it read, say, 10 things. Reading the 10th would
re-parse all previous 9, which is surely not what a programmer
might expect. The redexes (read sn) certainly look like thunks,
which we are accustomed to being shared. But actually it will
be evaluated once for each used variable in the LHS pattern.
Simon
