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 _______________________________________________ Haskell-prime mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-prime
