mapM /= traverse?

Dan Doel dan.doel at
Mon May 11 21:41:01 UTC 2015

The reason I know of why mapM wasn't just made to be an alias for traverse
(assuming that's what you mean) was that it was thought that particular
definitions of mapM could be more efficient than traverse. For instance:

    mapM :: Monad m => (a -> m b) -> [a] -> m [b]
    mapM f = go []
      go ys [] = return (reverse ys)
      go ys (x:xs) = f x >>= \y -> go (y:ys) xs

This doesn't use stack for m = IO, for instance.

However, it has since been pointed out (to me and Ed, at least), that this
matters much less now. Stack overflows are now off by default, and if you
measure the overall time and memory usage, traverse compares favorably to
this custom mapM. So, as long as stack isn't an artificially scarce
resource, there's no reason to keep them distinct. We didn't know this
until after 7.10, though.

If you're just asking why the definition of 'mapM' for lists isn't
'traverse' with a more specific type, I don't know the answer to that.

-- Dan

On Mon, May 11, 2015 at 3:15 PM, Simon Marlow <marlowsd at> wrote:

> I was hoping that in GHC 7.10 we would make mapM = traverse for lists, but
> it appears this isn't the case: the Traversable instance for lists
> overrides mapM to be the manually-defined version in terms of foldr.
> Why is this?  Fusion?
> Unfortunately since I want mapM = traverse (for Haxl) I'll need to
> continue to redefine it in our custom Prelude.
> Cheers,
> Simon
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list