Kevin Atkinson <[EMAIL PROTECTED]> wrote,
> "Manuel M. T. Chakravarty" wrote:
> >
> > Kevin Atkinson <[EMAIL PROTECTED]> wrote,
> >
> > > I take it that you are happy with names such as:
> > >
> > [long list of names deleted]
> > >
> > > I *hate* languages that try to keep things too simple. Which is one of
> > > the reasons I *hate* java. Please don't make me *hate* Haskell for the
> > > same reason.
> >
> > The problem with excessive overloading is that
>
> The key word here is excessive. If you are confusing your self by
> using the same name for everthing than you need to use seperate function
> names. So you are saying that haskell should avoid all featurs that can
> be abused.
Excessive by my definitions if the use of one function name
for `union' and `unionBy'. What's the harm in using two
function names here? Where overloading makes sense `union'
uses it already. If you have to use `unionBy', this is
because the elements of the set are not part of `Eq' or you
want to use something else than standard equality. In other
words, there is a good reason for using `unionBy' contained
in the algorithm or at least the structure of your program
(otherwise, you have probably already made a mistake in your
class definitions). As there is such a reason, you should
document it by using `unionBy' instead of `union' -
everything else is, frankly speaking, careless software
engineering.
Haskell encourages good software engineering practice -
that's something I very much like about the language.
> > (2) it makes it harder for beginners.
> >
> > Re (1): Consider the usage of different function names as a
> > form of additional documentation.
>
> Yes but many times excessively long function names can make code harder
> to read.
Come on - the two letters difference between `union' and
`unionBy' hardly make a program harder to read.
Manuel
