This is in response to your message about removing the overloading of list
operations in ``Questions on the Table''---actually it more in response to the
message about removing monad comprehension. I'm pretty new to Haskell (and
functional programming in general), but my understanding is that the existing
system is precisely the structure required to make comprehension notation
work, so why would the notation be weakened to just Lists?
This was actually one of the examples raised at the Haskell workshop, that motivated
the
decision to design Standard Haskell.
The problem is that if list operations, and especially list comprehensions, are
overloaded,
then in some programs the overloading will be ambiguous. In those cases the compiler
rejects the program, with an error message along the lines of
`ambiguous type variable in class Monad'
List comprehensions have only been overloaded since 1.4, and the change led to some of
my programs, for example, failing to compile for this reason. That was an irritation,
especially since Haskell lacks any good way to specify what the type variable should
be instantiated to. (Attaching a type declaration to a sub-expression is the way to do
it, but in general there may be no subexpression which can be given a list type: all we
know is that there is a subexpression whose type *involves* the list type, but may be
arbitrarily complicated).
These errors were irritating for me, but I'm an expert user. Imagine the first year
student,
taking the first programming course, who is struggling to understand list programming
and
recursion, and is suddenly faced with the error message above! It would be completely
incomprehensible; the beginning student doesn't even know what a type variable or a
class
is, much less a Monad. Improving the error message can't help here: the beginner
cannot be
expected to understand why there is an error at all. Since lists are such a ubiquitous
datatype in the very first programming exercises, it's vital that they can be used
without
the risk of stumbling across problems related to much more complicated concepts.
That's the motivation for renaming overloaded operators such as map, and retaining the
`classic' names for the classic list operations. Likewise it's the motivation for
restricting comprehension notation to lists. Remember that we also have the do notation
for monads, which is overloaded, and gives much the same power. Indeed it's hard to see
why two notations are needed if they both have the same types; when comprehensions are
restricted to lists then having the do notation as well seems much more natural.
Of course there are two sides to this argument too, but in this case we took a show of
hands
on it at the Haskell workshop. 90% voted to restrict comprehensions to lists.
John Hughes
