map and fmap

Iavor Diatchki iavor.diatchki at
Mon Aug 28 19:39:49 EDT 2006


On 8/28/06, John Hughes <rjmh at> wrote:
> 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.

I just checked the reports for Haskell 1.3 and 1.4 on the Haskell
website and they both state that the method of 'Functor' was 'map'.  I
only started using Haskell towards the end of 1.4, so I don't have
much experience with those versions of the language, but it seems that
having an overloaded 'map' was not much of a problem if only a few
people noticed.

> 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.

I don't think this example illustrates a problem with 'fmap'.  The
problem here is that we are using both an overloaded constructor
(return) and destructor (fold), and so nothing specifies the
intermediate representation.   The fact that 'map' removed the
ambiguity was really an accident. What if we did not need to apply a
function to all elements?
> example = fold (+) 0 (return 2)
It seems that we could use the same argument to reason  the 'return'
should have the type 'a -> [a]', or that we should not overload
'fold', which with the above type seems to be fairly list specific.


More information about the Haskell-prime mailing list