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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
