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