Re: Multiple return values

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
22 Apr 1997 21:05:27 -0400

          From comp.compilers

Related articles
[8 earlier articles]
Re: Multiple return values jbuck@Synopsys.COM (1997-04-18)
Re: Multiple return values smryan@mail.com (1997-04-20)
Re: Multiple return values danwang@dynamic.CS.Princeton.EDU (1997-04-20)
Re: Multiple return values smcadams@sprynet.com (steve mcadams) (1997-04-20)
Re: Multiple return values tiggr@es.ele.tue.nl (1997-04-20)
Re: Multiple return values hrubin@stat.purdue.edu (1997-04-20)
Re: Multiple return values fjh@mundook.cs.mu.OZ.AU (1997-04-22)
Re: Multiple return values roy@earthlight.co.nz (1997-04-22)
Re: Multiple return values Robert.Harley@inria.fr (1997-04-22)
Re: Multiple return values jashley@eecs.ukans.edu (Mike Ashley) (1997-04-22)
Re: Multiple return values burley@tweedledumb.cygnus.com (Craig Burley) (1997-04-22)
Re: Multiple return values albaugh@agames.com (1997-04-22)
Re: Multiple return values tiggr@es.ele.tue.nl (1997-04-30)
[15 later articles]
| List of all articles for this month |

From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.compilers,comp.lang.misc
Date: 22 Apr 1997 21:05:27 -0400
Organization: Comp Sci, University of Melbourne
References: 97-04-091 97-04-109 97-04-128
Keywords: design

>[Fergus Henderson 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);


smryan@mail.com (!@?*$%) writes:
>These are semantically distinct. The second requires additional notions
>such as variables, addresses, assignments, nonlocal side effects,
>aliassing, etc.


Well, what do you want -- do you want multiple return values for
efficiency, or for syntactic convenience, or both?


The issues you raise are mostly issues for C, because C doesn't really
have output mode arguments (you have to use pointers to simulate
them). These issues don't cause problems in languages such as Ada,
Sather, and Mercury. Using output mode arguments in these languages
give you both efficiency (the compiler can easily return multiple
results in registers) and syntactic convenience.


Herman Rubin complained about the "attrocious prenex syntax" of output
mode arguments, and while I think "attrocious" is a too strong, and I
don't think that there is necessarily anything wrong with using prefix
notation for this sort of thing, he does have a point: it certainly
helps if you can easily tell which arguments are input and which are
output. In the development environment I use, the mode declarations
are only a single keystroke away, but there is certainly an argument
for putting annotations for output arguments on the call, not just on
the procedure declaration.


The SML approach of providing nice syntax for functions that return
tuples can work too, but it requires a more sophisticated compiler to
make it efficient. Using a different calling convention for such
functions is not too difficult, but in a language with support for
Hindley/Milner style polymorphism like SML, the compiler needs to do a
bit of fancy footwork when you take the address of such a function.


I suppose the approach that Pieter Schoenmakers described is a
compromise; in his language "Tom", tuples are not first-class types,
and so it would probably be easy for a compiler to return tuples of
results in registers. But I think I'd prefer tuples to be first-class
types.


--
Fergus Henderson <fjh@cs.mu.oz.au>
WWW: <http://www.cs.mu.oz.au/~fjh>
PGP: finger fjh@128.250.37.3
--


Post a followup to this message

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