[Haskell-cafe] Re: Overloading functions based on arguments?

[Daniel Fischer]

Am Freitag, 13. Februar 2009 20:06 schrieb Jonathan Cast:
> On Fri, 2009-02-13 at 20:06 +0100, Daniel Fischer wrote:
> > Am Freitag, 13. Februar 2009 19:49 schrieb Jonathan Cast:
> > > It breaks type inference.  I explained this at the time.  I can explain
> > > it again:
> > >
> > >   import Data.List
> > >   import Data.Set
> > >   import Data.Map
> > >
> > >   warmFuzzyThingFirstOperation = map
> > >
> > > This gives an error currently.  Quite properly.  But if *any* use of
> > > `map' type-checks, with those imports, why on earth should this
> > > one fail? 
> >
> > To do justice to the above proposal, in that situation more than one
> > choice would typecheck (were the other imports absent or qualified), so
> > that should also be rejected according to it.
>
> Yeah, my objection is precisely that this trivial example is rejected.
> If this use of map is rejected, then I claim *every* use of map should
> be rejected.
>
Okay, why?
If warmFuzzyThingFirstOperation were accepted, it would have the type

(forall a b. (a -> b) -> [a] -> [b]) 
\/ (forall k a b. Ord k => (a -> b) -> Map k a -> Map k b)
\/ (forall a b. (Ord a, Ord b) => (a -> b) -> Set a -> Set b)

Looks kind of ambiguous, doesn't it? I would rather not allow that.
But if we have

take 5 (map (const True) [0,1,1,2,3,5,8,13,21,34,55])

we can infer that the 'map' used here must have a type unifyable with
Num a => (b -> Bool) -> [a] -> [c]
and only one of the 'map's in scope has such a type, so we must pick that.
Doesn't look sooo evil at first.
However, let us remove some information, what about

take 5 . map (const True)

? Well, still easy, we must unify with (a -> b) -> c -> [d], only one 
possibility, fine. Or is it? What if we have another 'take' in scope?
Say take :: Int -> Set a -> Set a ? Oops.
So, where draw the line?

> jcc

Bottom line, allowing that sort of overloading would at least be very 
ad-hoccish, and probably a bad thing.

Thanks,
Daniel