[comp.lang.misc] Multiple Return Values From Functions

dwtill@watyew.waterloo.edu (Dave Till) (07/14/89)

In article <1207@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>All is not lost, though.  In C, you can have
>
>	divrem(top, bottom, &quotient, &remainder)
>
>and something similar is possible with VAR parameters in Pascal (and
>Modula-2, I think).  This is symmetrical and reasonably elegant.  More
>elegant, I think, than complicating a language with multiple value
>expressions without adding enough power to do anything other than assign
>them to something.

I think it would be more elegant to allow the returning of multiple
values, as in

	[quotient,remainder] = divrem(top,bottom);

because then it would be clear that "quotient" and "remainder" are return
values, not input parameters or in-out parameters.
Using multiple return values also allows
the user to remove unnecessary dereferencing operations from the
called function.

>Basically, there's not much you can do with a multiple-value expression
>except ignore all but the first value (which happens if you nest a MV
>expression within a function call) and assign its results to variables.

I may have misunderstood what you are saying here, but I disagree:  I
believe it is possible to use a multi-valued expression as part of a
parameter list for a function call.  In fact, I believe that a parameter
list for a function call *is* a multiple-value expression.

I am trying to determine the applications of multiple-value expressions
and multiple return values from functions
as part of my master's thesis work, and would be happy to discuss this
by e-mail with anyone who is interested.  (I have written a C preprocessor
which implements constructs such as the above, and am trying to figure
out how useful these constructs are.)

Followups directed to comp.lang.misc, since this isn't really an
architecture-related issue any more.
--
--Dave Till, Computer Science Department, University of Waterloo
(dwtill@watyew.waterloo.edu)  ...<known universe>!watmath!watyew!dwtill
"Bottle, say after me, I must learn the difference between a lion and
a spider." -- Eccles to Bluebottle, the Goon Show, "Ned's Atomic Dustbin"

dik@cwi.nl (Dik T. Winter) (07/15/89)

In article <15141@watdragon.waterloo.edu> dwtill@watyew.waterloo.edu (Dave Till) writes:
 > I think it would be more elegant to allow the returning of multiple
 > values, as in
 > 
 > 	[quotient,remainder] = divrem(top,bottom);
 > 
Change this to:
	[quotient,remainder]:= divrem[top,bottom];
and you have Mesa, Xerocs language.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax

dwtill@watyew.waterloo.edu (Dave Till) (07/19/89)

In article <8271@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>In article <15141@watdragon.waterloo.edu> I wrote:
> > I think it would be more elegant to allow the returning of multiple
> > values, as in
> > 
> > 	[quotient,remainder] = divrem(top,bottom);
> > 
>Change this to:
>	[quotient,remainder]:= divrem[top,bottom];
>and you have Mesa, Xerocs language.

It may be splitting hairs, but I claim that in Mesa procedures return
records, not multiple values.  Inside a Mesa procedure, the fields
of the result record can be accessed as if they were local variables;
furthermore, outside the procedure,
the components of the result record can be assigned
using the extraction operation.  Thus, it *looks* like Mesa procedures are
returning multiple values, when in fact they're not.

Disclaimer:  the book I'm referencing documents Mesa version 5.0, which
is dated April 1979.  Are there newer versions of Mesa, and if so, do
they feature multiple return values?  Enquiring minds want to know! :-)
--
--Dave Till, Computer Science Department, University of Waterloo
(dwtill@watyew.waterloo.edu)  ...<known universe>!watmath!watyew!dwtill
"Bottle, say after me, I must learn the difference between a lion and
a spider." -- Eccles to Bluebottle, the Goon Show, "Ned's Atomic Dustbin"

dlm@sjfc.UUCP (Don Muench) (07/27/89)

Such a feature can be found in the new interactive language ISETL, a derivative
of SETL.  ISETL was written by Gary Levin, Clarkson U, Potsdam, NY 13676, USA.
I have used this language in teaching discrete math - it's very nice.  The
only book that refers to it is Baxter, Dubinsky, Levin, "Learning Discrete
Mathematics with ISETL",  Springer Verlag, 1989.

Workshops in ISETL have been given at the AMS/MAA meetings in January 1988
and 1989.  And in an NSF Faculty Enhancement workshop last June.

dlm@sjfc.UUCP (Don Muench) (07/27/89)

In article <584@sjfc.UUCP>, dlm@sjfc.UUCP (Don Muench) writes:
> Such a feature can be found in the new interactive language ISETL, a derivative
> of SETL.  ISETL was written by Gary Levin, Clarkson U, Potsdam, NY 13676, USA.
> I have used this language in teaching discrete math - it's very nice.  The
> only book that refers to it is Baxter, Dubinsky, Levin, "Learning Discrete
> Mathematics with ISETL",  Springer Verlag, 1989.
> 
> Workshops in ISETL have been given at the AMS/MAA meetings in January 1988
> and 1989.  And in an NSF Faculty Enhancement workshop last June.
I am sorry that I forgot my signature to my previous posting.  Here it is...
*************************************************************
	Don Muench
	Department of Mathematics & Computer Science
	St. John Fisher College
	Rochester, NY 14618
	Phone: (716) 385-8155
	E-mail: ...rutgers!rochester!cci632!sjfc!dlm
*************************************************************