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,[EMAIL PROTECTED] -> @x) [EMAIL PROTECTED] = 2})) ([EMAIL > >> PROTECTED] -> @x),[EMAIL PROTECTED] -> @x) [EMAIL PROTECTED] = 1} > >> (([EMAIL PROTECTED] -> @x,[EMAIL PROTECTED] -> @x) [EMAIL PROTECTED] = > >> 2},[EMAIL PROTECTED] -> @x) [EMAIL PROTECTED] = 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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
