Implict parameters and monomorphism

[John Launchbury]

This whole monomorphism-restriction debate was one that we had when we were writing the implicit parameters paper. We noted the dire impact of the monomorphism restriction, and commented upon it.

On reviewing the whole issue again I am forced again to conclude: There Is No Satisfactory Solution. At least not in Haskell as it is at the moment. Again and again I have been forced to conclude, the only thing worse than having the monomorphism restriction is not having the monomorphism restriction.

John's point about evaluation sharing is absolutely critical. We have to be able to distinguish between linear and exponential code, and not have the compiler switch from one to the other unpredictably. On the other hand, as Simon points out, having the MR changing program behavior silently is just as bad. And despite Lennart's comment, the situation is Much Worse with implicit parameters than with type classes. 

Aaarghh!!

So what to do? As a quick fix we should just pick one of A, B or C. Maybe A is the right one, prohibiting the problematical situation from arising at all.

For the long term, this issue provides strong supporting evidence for John H's suggestion of having two kinds of binding: the by-name binding has generalization (polymorphism, type classes, implicit parameters etc); and by need, without generalization (monomorphic).

As a meta comment: it would be good to hear from people who have made extensive use of implicit parameters, to find out how they are really used in practice. This can often provide quite surprising input. For example, in the original paper we argued that implicit bindings should not be recursive, because we expected a certain style of use would be quite common. Now is seems that other usage styles are more common, for which recursive bindings may be better. Oh well.

John