Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!bionet!arisia!roo!mark
From: mark@parc.xerox.com (Mark Weiser)
Newsgroups: comp.theory
Subject: Re: Procedures with multiple out parameters: why not?
Message-ID: <518@roo.UUCP>
Date: 19 Aug 90 01:28:50 GMT
References: <1990Aug15.231838.5664@zaphod.mps.ohio-state.edu> <21458@grebyn.com> <516@roo.UUCP> <2442@l.cc.purdue.edu>
Sender: news@parc.xerox.com
Lines: 40

In article <2442@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

>In article <516@roo.UUCP>, mark@parc.xerox.com (Mark Weiser) writes:
> 
>> ...
>> If the issue is something like value vs. var parameters, 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.

I don't quite understnd this.  LISP is in fact one of the languages in
which one hardly every uses reasonable return values, in the sense of
typed records.  Modula-(2 and 3), Cedar, Mesa, lots of others have
record returns.  I truly don't understand the comment about a record
being inadequate because of the drastically different types--a record
is that data structure one uses when one has drastically different
types.  C requires that to return a record one must separately define
it.  Cedar (e.g.) has the convention that the procedure
declaration defines an implicit record type to be the return value
(see my original posting, which was sort of pseudo Cedar).

>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.

I believe that the advice being given is that this is a practice to be
avoided.  Reading the code at the point of the call there is no
syntactic evidence about which parameters are which.  When huge
semantic differences are hidden by identical syntax, that is a bad
thing.

-mark
--
Spoken: Mark Weiser 	ARPA:	weiser@xerox.com	Phone: +1-415-494-4406