The discussion of overloading seems very abstract.
The question is really how overloading interacts with other language features.

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?  I know there are plans for a new module system,
what is the story there?

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?

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.
(Are existential types part of an implementation of overloading?).

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

How does overloading interact with operator precedence?  Can you have:
> (+)::String->String->String -- concatenate with precedence 5
> (+)::String->Int -> String -- concatenate with show(int) prec 5
> (*)::String->Int->String --copy string with precedence 4
> (*)::Int->String->String --copy string with precedence 6!!


So that:
2 * "foo" + "bar" =>  "foofoobar"
"foo" + "bar" * 2 => "foobarfoobar"
"foo" * 2 + "bar" => "foo2bar"

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

If you have overloading and prefix and postfix directives, you end up
with the ability to create very powerful domain specific languages.  This
power could be abused, but it could be very elegant.

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. 

Overloading also seems to have a very positive interaction with HDirect.
Exposing object from overloading languages like CORBA and COM IDL in
Haskell is really ugly because of the need to name mangle each variant of
a function name.  If we want Haskell to become a really useful scripting
language for objects created in other languages, overloading seems like a
requirement rather than an option.

----
There is a tradeoff between giving programmers a lot of power and
guaranteeing language readability.  My bias is towards the former,  IF 
you have a good module/reuse system/framework.  Program shortness can
compensate a lot for poor coding style.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   Shop.Com
1-212-697-0184 voice                    The Easiest Way To Shop






Reply via email to