On 2006-08-18 at 14:17+0200 John Hughes wrote:
Jon Fairbairn wrote:
...
The "beginners' prelude" would then consist of several modules that provided classless versions of the troublesome overloaded functions,
Hmmm.
I clearly don't teach the way you do.
Definitely! I clearly don't teach. (I'm unwell, condemmed largely to snipe from the sidelines)
"Folk who only get as far as doing arithmetic on Integers and Rationals with some simple stuff on Lists" doesn't include my students at the end of lecture 1! (That is, I start with different material).
That was really a guess about how your course must run, based on your argument.
I actually don't see much problem caused by the overloading of numbers, where teaching is concerned. Yes, it means that students see classes very early-- in error messages at least--but it's enough to tell them that Num a means a should be some kind of number (Integer or Double in my course). This is a small cost at the time I have to explain it. The good thing about doing so is that students start getting used to the idea of classes, and to distinguishing a class from a type, so that when I later introduce Eq and Ord constraints (which are very hard to get away from in reusable code), the concept of a class constraint is already familiar. Later on, when I show them wxHaskell, there are classes everywhere, but the basic idea is by then quite familiar. So I'm dubious that your idea of a beginners' prelude would really work better, even for teaching beginners! Type classes are such an essential part of Haskell that even beginners need to learn about them... but constructor classes (Monad, Functor etc) are another kettle of fish altogether.
Well, for you the "beginners' prelude" would only affect constructor classes, then. Actually, having thought about it further, I see a fundamental flaw in your argument. What it amounts to is that you /do/ want a beginners' prelude, but you want it to be the standard one. This does have negative effects. Partly because it's deeply ingrained, I find myself writing 'map' all over the place, thus constraining functions that would work on any monad to lists. I'm sure I'm not alone in this. I suspect that another part of it is that 'fmap' is a "noisier" name. I think Haskell should encourage people to think in terms of code that is as reusable as possible, so the "ordinary" map for Haskell should be the one for Functors. So I think what we should do (in this specific case) is essentially what Iavor suggested: provide a specialised function for mapping on lists and rename fmap. Quite what names we choose is another matter. A reasonable choice (forestalling the objection that using List.map, listMap or mapList would be too distracting for students) would be lmap:: (t -> t') -> [t] -> [t'] map:: Functor f => (t -> t') -> f t -> f t' Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk