Re: View on true ad-hoc overloading.

[Carlos Camarao de Figueiredo]

Hi Lennart, 

> ... But in a functional language it becomes much weaker since
> functions can be used without arguments (or fewer than the declared
> number when curried).

Yes. An overloading policy for a functional language should be a
context-dependent policy: it should be possible to overload, *for
example*:
  -- constants (e.g. integer literals, as in Haskell), 
  -- show and read functions, 
  -- toEnum, fromIntegral, fromRealFrac,
  -- some bulk type operations like leaves (given a tree, construct
     list, set or bag of leaves of the tree) (see SPJ's paper Bulk
     types with class),
  -- monad operations,
  -- map, fold. 

The functions above could be overloaded only with a context-dependent
policy, or, in other words, overloading cannot be resolved in general
in these cases by looking only at the argument type.

>  The more complex scheme using the result type is also not very good
> in a language like Haskell, because you can leave out so much type
> information.  What should be done if we write
>    x = X
> ?  This is ambigous in Haskell (given the declarations above).

> Is there a simple account for when the overloading will work
> and when it won't?  I don't know.  I suspect not.

We think there is. The full details are in fact not too simple
(although the general idea is very simple), but in our view its
advantages far outweights is complexity (cf. also Kevin's examples).

We would be happy to send anyone upon request a copy of our paper
"Type Inference for Overloading without Restrictions, Declarations or
Annotations", and extremely happy to hear any comments. The paper is
also available from http://www.dcc.ufmg.br/~camarao.

Yours truly, 

Carlos