The madness of implicit parameters: cured?

[Ben Rudiak-Gould]

On Mon, 4 Aug 2003, Ashley Yakeley wrote:

> At 2003-08-04 22:33, Ben Rudiak-Gould wrote:
> 
> >This illustrates what you pointed out earlier, that the
> >program's semantics can be changed by adding explicit type signatures
> >which include implicitly-parameterized parameters.
> 
> But wasn't avoiding this a design goal of your proposal?

Yes, and you convinced me that I had to give up on this goal. I'm attached
to my ideas, but only as long as they're right.


> >> If it is valid, then this must be a valid reduction:
> >> 
> >>   ((\a -> ((a,\@x -> @x) {@x = 2})) (\@x -> @x),\@x -> @x) {@x = 1}
> >>   ((\@x -> @x,\@x -> @x) {@x = 2},\@x -> @x) {@x = 1}
> >
> >Not unless you give an explicit type signature, no.
> 
> So effectively your proposal is the same as the existing implicit 
> parameter mechanism, except that the compiler is a bit stricter in 
> certain cases where the types are ambiguous?

Yes, it's effectively the same; that was the point. I'm not trying to
create a new language extension, but an improved conceptual foundation for
the existing extension. It's fine if I don't end up with quite the design
I expected, as long as it coheres. The important thing here is the *idea*
of treating implicit parameters as a special kind of named parameter,
rather than via a problematic analogy with Lisp dynamic typing. Everything
else falls naturally (and, I hope, inevitably) out of that idea.

This idea has been very successful so far. For one thing, I just found the
solution to the monomorphism restriction problem that people have been
struggling with for as long as implicit parameters have existed. The
reason I found that answer is that my new treatment changes the design
space in such a way that the solution falls out naturally with a little
coaxing. More than anything else, this makes me think that I've hit on the
right approach to implicit parameters.


-- Ben