map and fmap
rjmh at cs.chalmers.se
Mon Aug 28 15:41:08 EDT 2006
> On 8/22/06, John Meacham <john at repetae.net> 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.
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
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 , 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
More information about the Haskell-prime