Re: Multiple return values

Arthur.Chance@Smallworld.co.uk (Arthur Chance) writes:
>>Most programming languages allow procedures with multiple arguments
>>(in some cases allowing them to be used in curried form as well), but
>>very few languages allow multiple return values, in spite of the fact
>>that multiple results *are* multiple arguments when you're wearing
>>CPS-tinted glasses. Why is this?


Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:
>Many if not most programming languages allow procedures with
>multiple output arguments. For example, instead of


> (x, y) = foo(a, b);


>in C you can write


> foo(a, b, &x, &y);


This shows immediately that this is an inferior notation. It forces x
and y to be stored, as well as almost forcing a subroutine call.


>and in C++ or Ada you can write


> foo(a, b, x, y);


>and (at least to a first approximation) this is no less convenient.


This is a little better, but still has the atrocious prenex syntax.
SOME compilers will permit inlining the process, but even this can run
into problems with optimization, as well as generally not allowing
compiler local treatment of special cases.


A good example of something which is quite easy in hardware but
difficult in software, and which is now often not available on
computers, is


(exp, mant) =UP. float;


This would be the unpacking operation. Another is the use of
upper and lower products for a multiplication.


>Return values only provide syntactic convenience over and above
>output arguments in the single return value case, when you can
>avoid naming the result. For example,


> bar(baz(a));


>is more convenient than


> int tmp;
> baz(a, &tmp);
> bar(tmp);


There is that store and load again, as well as putting the address of
tmp on the stack. But it would be a good idea to have temporaries,
and to write something like


tmp = x baz y;
z = bar(tmp);


If the notation for temporaries is short enough (computer people do
not seem to like the short notation which mathematicians use; it does
make reading much easier for humans, even if not for computers), this
is almost as easy as writing


z = bar(x baz y);


>But in the multiple return value case, you're going to have to name
>the argument values anyway. Thus allowing multiple return values
>doesn't seem to buy you much over allowing output arguments.


>(Note that I'm not saying that allowing multiple return values is
>necessarily a bad idea, I'm just giving my guess as to the reasons
>for the historical data you observed.)


Anything which can be done on one computer can be done on any other,
if time and space is not of importance. With good computer parsing,
the languages should be for people to use easily and efficiently, and
not just for those who do not understand. This is why we need quick
ways of producing readable code for any operation which the user can
handle, whether or not the compiler writer or language designer has
thought of it. We WILL need a larger character set for this which can
be used in a WYSIWYG mode if the hardware can handle it, and the
corresponding tools.


The number of keystrokes to do infix or similar coding in the language
of a real or virtual machine is few more than using HLLs, if sensible
syntax is used, and the user can write macros with arbitrary syntax.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558
--

Return to the comp.compilers page.
Search the comp.compilers archives again.