John C. Peterson wrote:
> While some may argue that avoiding re-evaluation is the justification
> for the monomorphism restriction, the real issue is ambiguity.
> Without some form of monomorphism (or scoped type variables?? Someone
> needs to convince me that scoped type variables fix everything ...)
> you quickly run into some serious problems. For example, consider:
>
> 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.
--Jeff
P.S. C'mon, John. Don't you want to write your example as:
read s = let f () = reads s in fst (head (f ()))
;-)
(gratuitous () param to f thrown in to show we're not bothered by the
DMR)
