map and fmap

[Robert Dockins]

On Aug 14, 2006, at 3:00 PM, Iavor Diatchki wrote:

> Hello,
> I never liked the decision to rename 'map' to 'fmap', because it
> introduces two different names for the same thing (and I find the name
> `fmap' awkward).
>
> As far as I understand, this was done to make it easier to learn
> Haskell, by turning errors like "Cannot discharge constraint 'Functor
> X'" into "X =/= List".  I am not convinced that this motivation is
> justified, although I admit that I have very limited experience with
> teaching functional programming to complete beginners.  Still,
> students probably run into similar problems with overloaded literals,
> and I think, that a better approach to problems like these would be to
> have a simplified "learning Prelude" for the beginners class, rather
> than changing the standard libraries of the language (writing type
> signatures probably also helps...)

This idea has been kicked around a few times, but, AFAIK, it's never  
really been fleshed out.  Has anyone ever put anything concrete on  
the table?  It seems to me that most complaints are about hard-to- 
understand error messages, and these almost always arise from  
typeclasses.  They are especially confusing when they arise from  
syntax sugar.  I suppose a prelude with no typeclasses and compiler  
options to make all syntax non-overloaded would be one way to start.

On a related note, I've seen a number of Haskell design decisions  
justified by the "beginners find it difficult" argument.  Is this  
argument really valid?  Is there any reason not to just tell  
beginners to use Helium?  Is there a case for something between  
Helium and full H98 (or H')?


> Renaming 'fmap' to 'map' directly would probably break quite a bit of
> code, as all instances would have to change (although it worked when
> it was done the other way around, but there probably were fewer
> Haskell programs then?).  We could work around this by slowly phasing
> out 'fmap': for some time we could have both 'map' and 'fmap' to the
> 'Functor' class, with default definitions in terms of each other.  A
> comment in the documentation would say that 'fmap' is deprecated.  At
> some point, we could move 'fmap' out of the functor class, and even
> later we could completely remove it.
>
> This is not a big deal, but I thought I'd mention it, if we are
> considering small changes to the standard libraries.
>
> -Iavor


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG