On Wed, 19 May 1999, 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.
What I've always understood as the main argument for not allowing
overloading by return value still applies in a weaker form in Haskell,
namely:
int f(int a) & double f(int a) can't be resolved by the return value in
C++ because it's legal (& for an imperative language, sometimes sensible)
to call just f(5), the compiler automatically throwing away the return
value. For a pure function clearly this is meaningless since the only
effect of the function is to return a value. But, it's still legal &
sensible to write things like, for f::Int -> (Double,Double), y = fst (f
5), or even (_,_) = f 5. So you can't rely on type inference giving you
complete information about the return type and hence there will still be
sets of functions and usages which will result in unresolved
`ad-hoc-overloading'
I'm genuinely not sure whether the risk that adding a new function to my
program might suddenly make the overloading fail to resolve, giving really
cryptic error messages, is worth the convenience of (ad-hoc) overloaded
functions. (I'll admit ad-hoc overloading is useful for getting out of
trouble in C++ when I realise huge flaws in my overall design.)
___cheers,_dave______________________________________________________
email: [EMAIL PROTECTED] "`What sort of people would we be if
www.cs.bris.ac.uk/~tweed/pi.htm we didn't go into the Library?'
work tel: (0117) 954-5253 `Students.' -- Terry Pratchett
