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