Kevin Atkinson wrote:
> I was wondering what the generally felling to allowing true ad-hoc
> overloading like it is done in C++ in Java but more powerful because
> functions can also be overloaded by the return value.
>
> As I see it it will solve a hole series of problems:
>
> 1) Allow constructor identifiers to appear in more than one type.
> ie data A = X | Y
> data B = X | Y
>
> 2) Allow record selector names to clash.
>
> 3) Eliminate the need for all the *By functions
>
> 4) And many many more such as allowing
> array (range 1 to 10 step 2) ...
> array (1,10) ...
> array (range 1 to 10) ...
>
> w <- newWindow (buttons minimize maximize) (size 5 by 10 inches)
> w <- newWindow nobuttons (size 100 by 100)
> w <- newWindow
>
> which is possible due to the currying nature of Haskell
> (If you have never seen this before and would like to see
> how this is possible please let me know)
>
> So I was wondering if any one has given it any serious thought....
Yes, I've given this thought. And so have many others, I'm sure.
First, should it be done as in Java, where only the arguments are used
to resolve the overloading. Or should it be done as in Ada (can't
remember what C++ does right now) where both the arguments
and the expected result type are used.
I like the Java approach because it is simple to understand and
only requires buttom-up processing. But in a functional language
it becomes much weaker since functions can be used without
arguments (or fewer than the declared number when curried).
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 I won't? I don't know. I suspect not.
Still, I think this is something that is worth pondering, because the
current Haskell overloading, while quite nifty, isn't really what
I would want.
--
-- Lennart
