Re: map and fmap

On 8/22/06, John Meacham wrote:

...

I am not talking about type signatures, I am talking about having to annotate in the middle of a term.

f x y | x `member` map g freeVars y = ....

having to become

f x y | x `member` map g (freeVars y :: [Id]) = ....

There is no need to write such types... In this particular case the type of 'elem' indicates that the argument is a list. I don't think that a polymorphic 'map' function requires any more signatures than, say, '>>='. This certainly is not my experience when I use 'fmap'...

...

So, I am not saying renaming fmap to map is bad outright, I am just saying that the question is trickier than just the error message problem it was previously stated in terms of.

Do you have an example illustrating what is tricky about 'fmap'? As far as I understand 'map' used to be polymorphic, and later the distinction between 'map' and 'fmap' was specifically introduced to avoid the error messages that may confuse beginners.

-Iavor

No, map was never overloaded--it was list comprehensions that were overloaded as monad comprehensions in Haskell 1.4. That certainly did lead to problems of exactly the sort John M is describing. As for an example of fmap causing trouble, recall the code I posted last week sometime: class Foldable f where fold :: (a -> a -> a) -> a -> f a -> a instance Foldable [] where fold = foldr example = fold (+) 0 (fmap (+1) (return 2)) Here nothing fixes the type to be lists. When I posted this, someone called it contrived because I wrote return 2 rather than [2], which would have fixed the type of fmap to work over lists. But I don't think this is contrived, except perhaps that I reused return from the Monad class, rather than defining a new collection class with overloaded methods for both creating a singleton collection and folding an operator over a collection. This is a natural thing to do, in my opinion, and it leads directly to this example. John