The dreaded M-R

[Ben Rudiak-Gould]

Having thought about this for a while I'm coming down on the side of keeping 
some sort of monomorphism restriction, for the following reason.

It's hard to bound the space consumption of a Haskell program, but easy to 
bound its time consumption: its asymptotic runtime will be the same as or 
better than an "equivalent" ML program, because each bit of code gets 
evaluated at most once for every time that ML would evaluate it. Even 
optimistic evaluation preserves this property. Dropping the monomorphism 
restriction would break it.

I understand the theoretical appeal of polymorphism by default, but there's 
also a lot of theoretical appeal to dropping thunk updating, and in practice 
I dread both ideas. I don't want to have to think, every time I bind a 
variable, about whether it might be evaluated more than once. I also don't 
want to have to track down multiple-evaluation cases with runtime profiling. 
I want the compiler to notice these problems for me. So if polymorphism were 
the default, I would end up defensively requesting monomorphism almost all 
the time.

Therefore I'm strongly opposed to any proposal that requires a type 
signature for monomorphism, because it would create a large amount of work 
for me. I'm moderately opposed to the (x) = ... proposal, because it would 
uglify my code. I'm moderately in favor of John Hughes's original := 
proposal, because it seems less ugly.

Now, I rarely run into the monomorphism restriction as it stands because I 
rarely write point-free code. And I suspect this is what the debate is 
really about: it's the point-free people who usually want polymorphism 
versus the, uh, pointwise people who usually don't. For myself I'd be 
happiest keeping the monomorphism restriction as it now stands, but maybe 
John Hughes's proposal is the best compromise between the two camps 
(assuming they exist outside my imagination).

-- Ben