Re: View on true ad-hoc overloading.

[Carlos Camarao de Figueiredo]

Dear Alex Jacobson,

> For example, how does overloading interact with the module system?

I think these matters are ortogonal. In my view, parameterised modules
should be *the* nice way of grouping related functions/declarations
(modules could also be a form of type: see also "A View on Type
Declarations", at http://www.dcc.ufmg.br/~camarao).

> When you import a function from another module, do you need to
> specify a type as well as a name?  

There is a type inference algorithm that infers principal **typings**
(not only principal **types**), so that even types of imported symbols
could be inferred, without the need of specifying their types (but
perhaps it would be better to specify types of imported symbols
anyway...), and smartest recompilation could also be implemented.

> Does overloading mean that you don't need MPTC?  One of the nice
> things about type classes is they provide a nice way of grouping
> related functions.  Arguably, with overloading, this work would be
> done by the module system.  Is the module system powerful enough to
> support this?

Multi-parameter type classes are not needed. As done with Haskell type
classes, overloading of functions defined over different type
*constructors* can be defined (**without restrictions**). I think that
the grouping of related functions should as you said be done in
(possibly parameterised) modules.

> Does overloading mean that you don't need Existential types?
> Overloading would allow you to map a function over a list of various
> types (as in Java) and have the correct function be chosen for each
> type.  

I think issues here are ortogonal. Overloading does not perform
dynamic binding. I don't expect any problems in the interaction
between the two issues.

> (Are existential types part of an implementation of overloading?).

No.

> Does a combination of overloading and TREX make 'data' statements
> obsolete? Does it mean a more consistent TREX syntax?

I'm not very familiar with TREX, but I'll investigate. I don't think
it will make data statements obsolete.

> How does overloading interact with operator precedence?  Can you
> have: ...

Yes, you can have. In my view here "everything is fine". 

> There is already ambiguity about operator precedence and modules?
> Now it seems much worse.

I don't follow you here. 

> The interaction between polytypism and overloading seems particularly

I'm not very familiar with polytypism, but the possibility of
overloading functions defined over different type constructors may 
influence polytypic programming...

As I mentioned in a previous message, in my view the advantages of
unrestrictive overloading far outweight its disadvantages...

Carlos