map and fmap

[Jon Fairbairn]

On 2006-08-20 at 15:52+0200 "John Hughes" wrote:
> 
> From: "Jon Fairbairn" <jon.fairbairn at cl.cam.ac.uk>
> 
> > To reinforce what Aaron said, if a programme works now,
> > it'll still work if map suddenly means fmap.
> 
> Well, this isn't quite true, is it? Here's an example:
> 
> class Foldable f where
>   fold :: (a -> a -> a) -> a -> f a -> a
> 
> instance Foldable [] where
>   fold = foldr
> 
> example = fold (+) 0 (map (+1) (return 2))
> 
> example has the value 3 (of course), but if you replace
> map by fmap then the code no longer compiles.

The horror! Yet the code would still "work" in a sense,
because map is effectively fmap with a type signature
'(fmap::(a->b)->[a]->[b])'. Clearly the programmer meant to
write either 

> example = fold (+) 0 (fmap (+1) [2])

or something with a type signature to disambiguate the
"internal" overloading -- so I think it's probably a good
thing that this ends up producing an error message, since it
should have been given one in the first place! ;-)

> In any case, I'm dubious about this as a criterion. I
> would guess that the majority if compiler runs for
> beginners (and perhaps for the rest of us too!) end in a
> type error, not a successful compilation, so arguably the
> quality of error messages when a type-check fails is more
> important than which programs compile.

Certainly (we all want the best error messages possible),
except that we only need to worry about backwards
compatibility for programmes that used to compile. Are there
examples where replacing map with fmap changes the meaning
of the programme?

  Jón


-- 
Jón Fairbairn                              Jon.Fairbairn at cl.cam.ac.uk