On 20-May-1999, S. Alexander Jacobson <[EMAIL PROTECTED]> wrote:
> The discussion of overloading seems very abstract.
> The question is really how overloading interacts with other language features.
Your questions below are all good questions.
> For example, how does overloading interact with the module system?
> When you import a function from another module, do you need to specify a
> type as well as a name?
In Mercury, the current answer is that each module can only define one
function with a given name and arity (number of arguments), although you
can define multiple constructors with the same name and arity in a single
module. So overloading of functions only occurs between different modules,
not within a single module. However, a module can contain nested
modules, and it's OK for different nested modules of a single module to
define symbols with the same name.
The rationale for this is so that functions can be uniquely referred to by
just specifying a module name, function name, and arity, without needing
to specify the argument types. This keeps some things a little bit simpler.
> Does overloading mean that you don't need MPTC?
No. Type classes (including multiparameter type classes) serve a different
purpose than ad-hoc overloading.
> 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.
I disagree -- ad-hoc overloading is not a way of grouping related functions.
It is a way of allowing name clashes if the meaning is clear from the context.
It is a way of allowing functions which might or might not be related to share
the same name.
> Does overloading mean that you don't need Existential types?
No. Existential types are needed for creating heterogenous collections,
and overloading doesn't help with that.
> 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.
No, overloading doesn't give you polymorphism. Type classes and existential
types give you polymorphism.
> (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 think the answer to these questions is "no", but I don't know enough
about the details of TREX to give a definite answer on that one.
> How does overloading interact with operator precedence?
...
> There is already ambiguity about operator precedence and modules? Now it
> seems much worse.
Ah, now this is a tricky one. Mercury doesn't allow user-defined
operators, and the main reason for this is some tricky interactions
between operator precedence, the module system, and overloading.
Haskell avoids the problem with abiguity about operator precedence and
modules by requiring that any name clashes be resolved (by renaming)
at the time you import the module.
If you allow both overloading and user-defined operators, then there is
a difficulty, because parsing requires knowing the precedence of the
operators, and knowing the precedence of the operators requires having
performed overload resolution, but performing type checking and overload
resolution requires things to have already been parsed.
I think the best solution to this dilemma is to require the user to
insert explicit parentheses whenever overload resolution might affect
the parse. The compiler would keep track of all the different possible
precedences of each operator, or at least of the minimum and maximum
precedence; whenever it sees "x `op1` y `op2` z", it would compare
the minimum precedence of `op1` with the maximum precedence of `op2'
and the maximum precedence of `op1` with the minumum precedence of `op2';
if the two comparisons give different results, then it would report
a syntax error (e.g. "this syntax is ambiguous, due to operator overloading;
please insert explicit parentheses to resolve the ambiguity").
> The interaction between polytypism and overloading seems particularly
> powerful because polytypic functions don't need to worry about namespace
> polution on function names. e.g. you don't have to create a HasSize class
> to create a generic 'size' function. But the syntax of derive and the
> polytypic extentions needs to be rethought in the presence of such
> features.
This is another area where I don't have enough knowledge to give any
definitive comment. Perhaps someone who is more familiar with polytypism
and the syntax used by "derive" could comment on the possible interactions
of that and ad-hoc overloading?
Cheers,
Fergus.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
