On 2006-08-20 at 15:52+0200 "John Hughes" wrote: > > From: "Jon Fairbairn" <[EMAIL PROTECTED]> > > > 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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
