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
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
