Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.lang.misc
Subject: Re: Language Tenets (too long)
Message-ID: <8820@june.cs.washington.edu>
Date: 27 Jul 89 16:07:59 GMT
References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp> <1207@quintus.UUCP> <1406@l.cc.purdue.edu> <1989Jul17.184707.415@maths.nott.ac.uk> <1223@quintus.UUCP>
Reply-To: pardo@june.cs.washington.edu (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Lines: 41
Disorganization: University of Washington, Computer Science, Seattle

In article <1223@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>[Multiple return semantics]
>[1. Packed in to a single structure to return.]
>[2. Put them in the actual variables.]
>[Cleanest: just use VAR parameters.]
>	    divrem(write(fd,buf,BIGBSIZE), BSIZE, &records[i++], &errcount);

Even in languages without explicit aliasing, aliasing still occurs.
This is a case in point.  When I pass VAR parameters to this
function, I expect them to be changed when the function returns.
But what if the function changes a result that is also used as an
input value?  Most languages don't pass arrays by value, they pass
them by reference.  Aliasing problem number one:

	foo (x, &x[2], &y[2]);

	...

	foo (int i[], int *j, int *k)
	{
	    *j = i[2]+1;
	    *k = i[2]+2;	/* But what if i[2] is (*j)? */
	}

The first point here is that `j' and `k' aren't really VAR
parameters, they are Ada's OUT parameters.  If this is truly a
function and the value of *j depends on the old value of *j, then
that value should be passed separately.

To make `foo' work correctly, it is necessary to disallow aliasing
somehow.  One way is a `noalias' qualifier that says "`j' and `k'
may not be aliases for ay part of `i'".  If the compiler has this
information at the call site, it can often (not always) verify
noalias, and can always enforce noalias.  Another way is to have
multiple return values whose semantics are like those of single
return values.

	;-D on  ( You've won a RETURN VALUE, Mrs. Smith! )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo