On Tue, Jul 28, 2009 at 1:41 AM, Heinrich
Apfelmus
While I do agree that qualified names are annoying at times, I think that type directed name disambiguation is a Pandora's box.
I see where you are going, but I'm not sure I agree. Let me give an example from another language with this kind of resolution: C++. From a purely practical point of view, function overloading in C++ does what I want almost all the time. And when it doesn't do what I want, it's always been immediately obvious, and it's a sign that my design is flawed. But those cases where it does what I want have been incredibly useful.
Furthermore, we already have a mechanism for type based disambiguation, namely good old type classes. For instance, the qualifications required when importing Data.Map are actually a sign that we are lacking proper container type classes à la Edison.
Perhaps. I think containers is a great example of why you want TDNR. Many containers have *almost* the same interface, but not quite. After all, if the interface was the same, you would just find the most efficient container for that interface and call it a day. So unless you want to go the direction of putting every single container-related function in its own typeclass, I don't think you'll be able to come up with "one container interface to rule them all". To be fair, I'm not against the idea of putting each function in its own typeclass. For work along these lines, see the many "better numeric hierarchy" attempts. But I'd also need support for class aliases or something similar so that defining common subsets of those classes would work easily. Along those lines, what about being able to elide class names when they can be unambiguously determined from the functions defined? instance _ [] where fmap = map pure x = [x] fs <*> xs = [ f x | f <- fs, x <- xs ] return x = [x] m >>= f = concatMap f m This would define Functor, Applicative, and Monad for []. -- ryan