Complications:
* In my examples it's easy to tell whether all uses of the implicit
parameter refer to the same explicit binding, but it may be difficult
when recursion is involved. This problem has already arisen in the
case of type class constraints, and has been solved, so I'm
On Tue, 5 Aug 2003, Simon Peyton-Jones wrote:
I'm afraid that I have not read all of the recent exciting flood of
messages carefully,
Hi, I'm glad to see that you're around, and I'm very much looking forward
to any comments you may have about my proposal.
You say that All implementations
I wrote:
Exactly the same rule should apply to implicit parameters. In the case of
implicit parameters, safety is ensured if in every use of the bound
variable, its implicit parameter refers to the same explicit binding of
that parameter. For example, the expression
let g = ?x in
I wrote:
My solution *is* the Right Thing. :-)
What I meant is: it always preserves the validity of inlining, it always
preserves sharing, and it rejects otherwise-correct programs only in
situations which are (I expect) uncommon in practice.
-- Ben
I just figured out why the monomorphism restriction interacts so weirdly
with implicit parameters, and how to fix it.
We all know that when the monomorphism restriction is turned on, the
following doesn't work:
let f = () in (f 1 2, f 'a' 'b')
On the other hand, the following does work:
| I just figured out why the monomorphism restriction interacts so
weirdly
| with implicit parameters, and how to fix it.
I'm afraid that I have not read all of the recent exciting flood of
messages carefully, but I do remember that the interaction of the
monomorphism restriction with implicit
