Re: Multiple return values

  Arthur.Chance@Smallworld.co.uk (Arthur Chance) wrote:
> > A thought struck me over the weekend while rereading the "Lambda: the
> > Ultimate <foo>" papers:
> >
> > 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?


marssaxman <marssaxman%sprynet.com.antispam@nac.no> wrote:
> I think it is an artefact of the origin of the "function" concept. The
> idea of a function in maths is that you give it some parameters and it
> performs some calculation on them. The result of the calculation is
> the return value. It doesn't make sense to have, for example, an
> arctangent return more than one value. Given the origins of computing
> in maths it is easy to see why this habit has been carried on.


That, and multiple values are generally more difficult to deal with
(both in the specification of the langauage, and implementation). You
are forced to effectively bundle the return values into some sort of
structure, or have the whole architecture of the language structured
to deal with this (adding results to lists).


However, on the plus side, I think that multiple returns are a useful
concept in functional languages where functions are only allowed to
return results, as having to set up a structure for each time there
might be more than one thing to return, and then pull bits out of the
structure in the calling function, is a little painful.


In the langauage I have written / am writing (ReWrite), not only can
functions accept an arbitrary number of arbitrarily typed arguments,
they can return an arbitrary number of arbitrarily typed results.
This means that except where the compiler has some more specific
information about particular functions, all arguments have to be
passed and results returned on the heap, so the cost of this extra
flexibility is a performance loss, and you can no longer in general
even make any compile time assumptions about how many arguments you
are passed.


An example:


g[0] -> ;
g[n:int] -> g[n-1],n;


f[g[5],g[3]] will evaluate f[1,2,3,4,5,1,2,3]


f has to be able to accept an arbitrary number of arguments and
could be (say):


f[.x] -> add[.x];


which would return 21.


You can do the same sort of thing in Mathematica, but that doesn't
have the problem of needing to be compiled.


I'd be interested to hear about any other languages that to this.


Roy Ward
roy@earthlight.co.nz
--

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