Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.theory
Subject: Re: Procedures with multiple out parameters: why not?
Message-ID: <2442@l.cc.purdue.edu>
Date: 17 Aug 90 19:28:05 GMT
References: <1990Aug15.231838.5664@zaphod.mps.ohio-state.edu> <21458@grebyn.com> <516@roo.UUCP>
Organization: Purdue University Statistics Department
Lines: 29

In article <516@roo.UUCP>, mark@parc.xerox.com (Mark Weiser) writes:
 
> Perhaps it depends on what counts as more than one out parameter.
 
> Many languages permit the return of record structures, and the selection
> of components as part of the call.  This could be argued as a form of
> multiple out parameters.  (e.g.:
> 	PROC foo [] RETURNS RECORD [i,j: INT];
 	...
> 	x = foo[].i;
 
> If the issue is something like value vs. var parameters, then the restriction
> could be restated as saying that it is bad to have ANY out parameters (i.e.
> any var parameters)--only return of a (possibly complex value) should be
> permitted.  This seems to be in agreement with formal practice also.  I would
> guess it is in line with Dijkstra's intent.

This is far too restrictive.  The only present HLL I know of which has full
multiple results for an operation is LISP.  That the others do not was, in
my opinion, massive oversight.  Outputting a record would not be adequate,
as the items output may have drastically different types.

If one does not worry about storage and access problems, there is no problem.
The output variables can be explicitly listed as arguments of the procedure
which returns VOID.  This has been used since antiquity/
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)