From: chetl@donald.tamu.edu (Chet Laughlin)
Newsgroups: comp.misc
Subject: Re: functions & return values (was Re: Reinventing the wheel)
Date: 15 Apr 92 15:38:41 GMT
Organization: College of Architecture, Texas A&M University

In article <MJD.92Apr14135347@saul.cis.upenn.edu> mjd@saul.cis.upenn.edu (Not James E. Pommersheim in disguise) writes:
>In article <1992Apr14.154725.9397@cs.unca.edu> mcmahan@cs.unca.edu (Scott McMahan -- Genesis mailing list owner) writes:
>>   Functions that return more than one value!?
>>   That's terrible -- why would anyone *want* to do this? If it needs to
>>   return more than one value, it would be a lot easier to implement 
>>   and understand it if you just passed them in as parameters.
>
>    I don't agree; I think that's just because you're used to C, which
>does things a certain way.  The only difference between a function which
>returns multiple values and function which returns a structure or an
>array is a matter of language semantics, and surely returning a
>structure (which C can do) is reasonable?

I never *saw* a reason to pass more than a single structure during my
work until I started programming in a language that *let* me perform
such feats.  At my current job, I write PostScript and Fifth code which both let
me do such things.  Fifth is a derivitive of Forth [sp?].  Today, I
notice just how ugly all those var keywords were in my old Pascal and
the needless pointers in C code because one simply could not return
multiple data objects on the data stack.

I'm sure one could cover most situations by making the returned stack
structure hold all the needed return values.  But this sounds too close
to a kludge in my opinion - because it does not address the need to
return a varying amount of data.  Imagine the need to return n groups of
items.  As a side note, this seems very close to the old static memory
allocation vs. dynamic memory allocation debate.  Sure, one can write a
FORTRAN program that will do what most C programs do - and in static memory.
But would you *WANT* too?  Would you want to _maintain_ it?  Is the result
readable?  How close is the program to the algorithm it impliments?
If the algorithm produces multiple outputs shouldn't the program module?

As for the claim that keeping track of what goes in and goes out is too
complex - well I'm not sure what your real underlying problem there is.  If
one works in a large development group you *can't* memorize all the interface
specifications anyway so whats the point?  If the interface is _intuitive_
then it doesn't matter if its one in and one out or many in and many out.
For example.  I have worked on a routine that trims the whitespace off a 
PostScript character.  Its input is a varying number of run length encoded
scanlines on the data stack.  Its output is a different number of scanlines
with minimal whitespace.  The number of lines differ because one can chop off
leading and trailing scanlines that are blank.  Now, would this be more
intuitive with a single return data structure?  I don't believe one could
find a clear cut 'yes' when sampling a group.

---------------------------------------------------------------------
| Chet Laughlin                  reply:chetl@archone.tamu.edu       |
| "There is no Computer Science, it is all witchcraft."             |
|                                MIT Math department, 1958          |
| I do not speak for Texas A&M University, and they rarely speak    |
| for me.                                                           |
---------------------------------------------------------------------
~
Newsgroups: comp.misc