At 09:36 +0100 1999/05/19, D. Tweed wrote:
>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.
What is a feature of C++ is in fact also a flaw:
The proper view (I think) of the fact that one is not forced to take care
of return values is that together with a function of type A f(B),
implicitly also a function of type void f(B) is created. Thus the fact
that it is not possible to resolve the name overloading of int f(int a)
and double f(int a) is due to the fact that both functions implicitly
create a function of type void f(int), and these two functions conflict.
A computer language should provide means to allow control over these
implicitly created functions of type void f(B).
In fact, I came across this problem in C++ quite recently, attempting to
implement a language transparent "tail recursive evaluator" style type of
jump from a finishing function to another. Without such language control,
it turns out to not be possible to implement it in a language transparent
manner (that is, so that the one using the feature needs not worry about
the implementation details).
Hans Aberg
* Email: Hans Aberg <mailto:[EMAIL PROTECTED]>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
