> What would be gained by allowing ad hoc overloading? If
> operations on different types have similar meaning
> there is a case for defining a new class. If you have existing
> different functions with similar names you can
> qualify them to avoid the ambiguity. When else would you want
> this feature?
I'm not at all sure whether I'm in favor of this kind of overloading. It's a
difficult issue. However, it's used all the time in mathematical text, and
Haskell goes a long way to make a program look like conventional
mathematical syntax (function clauses, list comprehensions, etc.), so one
might argue, why not allow overloading as well? That said, I'm leary of
identifier overloading because it can be used in ways that end up assigning
it a semantic significance, and in these cases I think type classes should
be used instead. If overloading could be restricted so that it can't be used
for, for example, hiding the type or denotation of a variable, and only to
lessen the burden of finding distinct names for things, then I think I would
be in favor of it. For example, we generally write + for the coproduct in
any category, so "this is a coproduct => write it as +", but we don't reason
in the other direction, i.e., "this operator is written + => I know it is a
coproduct." The point is that the notation should reinforce, but not
influence, the semantics.
--FC
