map and fmap

[John Hughes]

From: Robert Dockins <robdockins at fastmail.fm>
 

    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')? 

I have a lot of experience of teaching beginners--I've been doing it for years, and have seen the effects of introducing functional programming at various stages in the curriculum, and in various ways. That's given me a strong desire to ensure there is an easy learning path into Haskell.

One thing I've observed repeatedly is that many students in later years, who learned functional programming early, have a strong impression that functional languages are only suitable for toy programs. Of course, that's because in their first courses they only SAW toy programs. But perhaps, they also moved on to Java as soon as they started to build GUIs, and as a result have the impression that you CAN'T build a GUI in the functional language they learned first.

This is a very negative impression for students to have, and one that is hard to combat because beginning undergraduates are sceptical to functional languages from the word go: they "know" they really want to learn C++ or Java, and wonder initially what we're playing at.

I combat that--successfully--by showing them early on that Haskell *is* a "real" programming language, in which one can build real applications. I tell them about darcs, or whatever new application is hot at the time. I show them how to build a GUI in wxHaskell--in the fifth week of their university studies. I want them to be frustrated at how difficult GUI programming is when they do it in Java (:-)! It works--some find it very hard, but many of the good students go much further than my lectures and exercises, and reappear in the third and fourth years as very expert and enthusiastic Haskell programmers.

Now, this approach couldn't work if the language I taught really WAS only suitable for toy programs! Even a "beginner's prelude" would introduce a discontinuity for students, making it harder to take the step from course exercises to real programs, and that would mean that fewer of my students would end up as Haskell enthusiasts. I'd be very sad about that.

On the specific point of map vs. fmap, it's true that similar difficulties DO arise for numeric literals, and a partial solution is to tell students to write type signatures at the beginning. However, this isn't a complete solution, because students still see plenty of class constraints in error messages, and they need to understand them sufficiently well to fix their errors. It's not too hard to explain that "Num a" means that a should be a numeric type--Integer, Double, i.e. a type they are familiar with. It's much harder to explain what "Functor f" means to a student who's still struggling to keep in mind the difference not just between a type and a class, but between a type and a value. The fact that f is a type constructor, and not a familiar type, is an additional obstacle. That makes overloading list operations much more of an obstacle for beginners, than overloading numeric operations is.

The other thing to remember is that, even when students write type signatures, overloading ambiguities may still arise within their definitions. This is not usually much a problem for numeric types, because they are defaulted to Integer or Double. Making overloaded list operations easy to use for beginners would, I suspect, require defaulting rules for other classes--defaulting Functor and Monad to lists, for example. This is a whole new can of worms.

John