> I'm confused. I thought at the ICFP Haskell meeting we agreed
> on the following types:
>
> length :: Integral i => [a] -> i
> take, drop :: Integeral i => i -> [a] -> [a]
> showsPrec :: (Show a, Integral i) => i -> a -> ShowS
> I'm not against adopting a conservative design if there is a problem,
> but then Simon ought to explain what the problem is.
Could I remount the Clapham omnibus and explain why I would like to retain the
status quo.
Wasn't there a similar change made between Haskell 1.3 and Haskell 1.4 when the
list processing operations were generalised to work with monads, and it was
thought to be a bad thing, if only because type error messages took a turn for
the worse; too few programs exploited the extra generality to make it
worthwhile. Is there going to be a similar problem this time?
I am using Haskell to teach a problem-solving course to our first years (it
accounts for 25% of their first year C.S. input, with 37.5% being based on
Java, and the rest a computer architecture course). Our class sizes are
heading for the 200 mark. Although they have to learn two contrasting styles
of programming (itself a big plus point, but set against that it does stress
the students and risk confusion for some students) part of my reasoning is that
a a functional programming language is (or should be) much, much simpler than a
corresponding imperative programming language, particularly one like Java.
This argument is seriously undermined if I have to get involved in type classes
so I simply avoid them (along with a host of other things including the `data'
statement, though I may get around to it this year).
To maintain this illusion I tell them that the type signature for map is
map :: (a->b) -> [a] -> [b]
and discourage them from using reading the prelude or using the Hugs `:t'
command. At the moment this is just about workable but if these changes should
go through and they rebound in a worse way than the Haskell 1.4 changes then I
may have to reconsider. Additionally, I would like to persuade one of my
colleagues to use Haskell to complement Java in teaching a second year data
structure course, and I am quite sure that that would be a non-starter if he
felt that a mastery of type classes by him or the students were necessary. It
would be particularly bad news if the text books and the compilers/interpreters
were to become out of step.
Careful subsetting also creates space for teaching them topics that are likely
to appeal to them such as simple graphics and GUIs (again possible through
careful packaging, made possible by the overloaded `do' notation).
In summary: making changes can have all sorts of subtle affects, in this case
*maybe* nuking a strategy of teaching a subset of the language.
Just thinking for a moment as a programmer/researcher interested in using
Haskell to do things I would vote the recent stability of Haskell, particularly
the convergence of Hugs and GHC, as by far the best thing that has happened to
Haskell since, say, the introduction of monadic I/O.
Set against such risks, seen and unseen, what are the potential benefits of
such a change?
Cheers,
Chris
