On Thursday, May 20, 1999 3:58 PM, Kevin Atkinson [SMTP:[EMAIL PROTECTED]]
wrote:
> True ad-hoc overloading can lead to unreadable programs if it is
> misused. However it can make code more readable and concise if used
> properly.
>
I can't disagree with this. But I can object to it. The words "used
properly" ask more than it is
reasonable to expect.
What follows is not directed at Kevin, but is a general plea for the
defence of Haskell.
Programs for real world applications and programs which will be read by
other people (or even by the author
some time after writing them) must be correct, clear and unambiguous.
Unambiguity implies not just that the compiler will not be confused, but
that Joe Programmer will not be confused when reading a program to fix a
bug or to modify it
to reflect a change in requirements. To allow ad hoc overloading is to
invite errors resulting from that kind of confusion.
This is why Haskell, from the beginning, has had type classes but not a
rbitrary overloading.
Language design includes human factors issues. If you want a language so
full of neat features that it will accept
anything the compiler can make sense of, try PL/1. Or (if you are old
enough to remember) write your name in Teco,
and try to work out what it means. We tried to learn from the early
experience of language design. Haskell is
an advance on previous languages.
Haskell is a general purpose language. It is not a specialised language for
doing mathematics. It should not be
a language that can only be written and understood by specialist experts.
If we believe that functional languages
are superior and want them adopted widely, we must ensure that they are
attractive to and usable by people in the computer industry. Perhaps even
Microsoft people :-).
If you want a different language, tailored to your special needs, then
define it and implement it - write a pre-processor
to convert it to Haskell if you like, but please do not try to change the
essential character of Haskell.
--brian
