I hate to reopen an old debate but here goes.
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'. In fact, the general idiom
(x,y) = exp
becomes rather hazy without monomorphism since the computations
associated with x and y may differ.
This debate always gets clouded up by folks who consider the various
overloaded guises of an expression to be equivilant in some way.
For example, in
x :: Num a => a
x = 1
the fact that x may be a float in one context and an integer in
another doesn't bother anyone - it's fundamantally the same value
(aside from recomputation issues!). However, in classes such as Read,
there's no relationship at all between values produced by an
expression at different overloadings.
I won't argue that the present monomorphism rule is perfect, but it
does address a real issue besides recomputation.
John
