map and fmap

[Jon Fairbairn]

I don't really have the stamina to keep up with discussions
like this. I have a bit more now than the first time round,
so here's some more...

On 2006-08-29 at 07:58+0200 "John Hughes" wrote:

> On the contrary, it seems we had plenty of experience with an overloaded 
> map--it was in the language for two and a half years,

During which there were fewer users, as you note below.

> and two language versions. In the light of that
> experience, the Haskell 98 committee evidently decided
> that overloading map was a mistake, and introduced fmap
> for the overloaded version.

One might say that your experience persuaded the committee
to do this.

> Now, this was an incompatible change, and the Haskell
> committee was always very wary of making such changes--so
> there must have been a weight of experience suggesting
> that overloading map really was a mistake.

For teaching, yes.

> It wouldn't have been changed on the basis of abstract
> discussions of small examples. My own bad experiences with
> list overloading were with monad comprehensions, but
> others must have had bad experiences with overloaded map
> also. Given that it's been tried--and tried so
> thoroughly--and then abandoned, I would be very wary of
> reintroducing it.

I don't think you can conclude that from the evidence
available (ie the link, posted by Ross Paterson, to the
discussion at the time)

> We didn't simplify things in Haskell 98 for the sake of
> it--we simplified things because users were complaining
> that actually using the language had become too complex,
> that there were too many corners to stumble on.


This is where I most heartily disagree. Whatever the
arguments for and against, what was done was /not/ a
simplification of the language.

I cannot see how it can be argued that a language where

* the functorial map has three names (fmap, liftM and map)
  at different types

* and the general functorial map (fmap) can be applied only
  to some Monads (the ones where an instance has explicitly
  given)

is simpler than a language where

* the functorial map is called map.

Your argument that teaching the former language is simpler
is very strong and I don't dispute it, but it is not, I
think, a reason to require that people who want to use the
language to have to put up with remembering extra
complexity.  Once one knows what functors and monads are
(and no one can call themselves an expert Haskell programmer
who does not), one should not have to think "does this Monad
have an instance of Functor, or must I use liftM?" or is
this function /really/ meant to work only on lists, or can I
replace map with fmap and get it to work on something else
(and then find that it requires copying out the whole
definition because it also uses ++ or something).

Yes, it makes perfect sense to have

> mapList = (map :: (a->b) -> [a] -> [b])

in a prelude somewhere for teaching purposes, but aren't
people eventually taught that mapList is just a specialised
version of map, ++ is `mplus` specialised to lists (etc),
and that one should think in terms of defining operations
that are as generally useful as possible?

At which point don't some of them start to wish that they
could just type ++ instead of mplus? I certainly do. If it
were just a question of map and fmap, I might agree that the
cost would outweigh the benefit, but there's a whole swathe
of functions for which I'd rather see the nicer names used
for the more general versions, and clumsier ones for the
versions specialised to lists for teaching purposes.

We would all benefit from better error messages, but that's
a different problem.

> I think we did a good job--certainly, the Haskell
> community began growing considerably faster once Haskell
> 98 came out.

I'm not sure there's a causal relationship there. If the
growth was anything above linear, it would be growing faster
later whether or not Haskell 98 had an effect. Even if
Haskell 98 was the cause, it's far from obvious that this
particular change was the one that made the
difference... and if it did, it may not have done so for a
good reason.  If you make the language easier to understand
it may well become more popular (there are plenty of awfully
popular awful languages out there for more or less that
reason), but if it's at the expense of unnecessarily complex
programmes, we shouldn't be applauding ourselves too much.

In addition, it seems likely that as more and more people
get a deeper understanding of Functors, Applicators and
Monads, we'll find better ways of teaching them.

 Jón


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