From: Robert Dockins <[EMAIL PROTECTED]>
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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
