On 2006-08-20 at 15:52+0200 "John Hughes" wrote:
From: "Jon Fairbairn"
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