[Haskell-cafe] Re: Proposal: TypeDirectedNameResolution

[Ryan Ingram]

On Tue, Jul 28, 2009 at 1:41 AM, Heinrich
Apfelmus<apfelmus at quantentunnel.de> wrote:
> 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