Re: View on true ad-hoc overloading.

[Carlos Camarao de Figueiredo]

Dear Jan, 

there is no need to restrict overloading with functions with the same
number of arguments. 

In your example: 

   int sum(int a,int b) { /* obvious code here */ }
   int sum(int a,int b,int c) { /* ditto */ }

   apply :: Int -> a -> a 
   apply (n::Int) _ = error "Can't apply integers!"

   apply :: (a -> b) -> a -> b
   apply f x = f x 

   apply (sum 3 4) 5? 

(sum 3 4) can have either type Int or Int -> Int, 
apply (sum 3 4) 5 could only have type Int, 
but since overloading has not been resolved and in this case could not
be resolved lateron, an ambiguity error must be issued (assuming also
that there is no mechanism of choosing a default to resolve the 
overloading.)

The situation is the same in Nigel Perry's example: 

        let f : int -> real == ....
        let f : int -> char == ...

        let g : real -> bool == ...
        let g: char -> bool == ...

        .... if g(f x) .... <- ambiguous


We did not know of Nigel Perry's work with Hope+C. We plan to
investigate (it seems a little strange to provide type inference and
also require top-level type declarations). 

We would like also to comment on Brian Boutel's question: 

  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?

We think that qualifying names may clutter your code. More
importantly, you would not have to worry about what is and is not
"similar" (consider e.g. +, *, <, >= etc.). You would not be required
to anticipate all possible uses of a symbol with "similar meaning", in
order to give it a type that is the least common geneneralisation of
the types of all its possible instances. Several examples have
appeared in this list for the definition of libraries for algebraic
operations. As a final note, the explicit use of contexts in type
declarations conflicts with data abstracion: if an implementation is
changed so that it does not use anymore an overloaded symbol, or uses
a different overloaded symbol, the types of symbols defined by using
this (changed) symbol must be modified. More details can be found in
our paper "Type Inference for Overloading without Restrictions,
Declarations or Annotations"(http://www.dcc.ufmg.br/~camarao).

Carlos