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