[Haskell-cafe] Re: Overloading functions based on arguments?
daniel.is.fischer at web.de
Fri Feb 13 15:38:21 EST 2009
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.
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?
Bottom line, allowing that sort of overloading would at least be very
ad-hoccish, and probably a bad thing.
More information about the Haskell-Cafe