Re: Returns vs. retrieves? (Lengthy)

[Linda Sherman <linsherm -at- GTE -dot- NET>]

I apologize for the long answer, but I think this is an issue that many
technical writers might encounter in their work, and so far all I've
seen is a great deal of misinformation on the subject. For example:

> "returns" is more correct
> programmer-speak. The word originates in the old BASIC
> programming construct of "GOSUB" (go to the following subroutine)
> and RETURN

This isn't correct, but neither are any of the other explanations I've
seen so far. (Apologies if someone else has already explained this
correctly and I missed it...email has been a bit shaky here the past few
days).

There are two meanings of "return" in computer programming. They have
entirely different origins and really have very little to do with each
other. The assumption that they are related is understandable, and comes
from the fact that in some languages (not all) the "return" instruction
means both "return from executing" and "return a result." But this is
merely an implementation feature for the convenience of programmers; the
two really don't have anything to do with each other, and in some
languages (Pascal, for example) returning the result is done in a
different instruction than the one that returns from the subroutine.

Meaning #1: "return from executing a subroutine"
(intransitive verb)

Early computers had limited memory--an 8K machine was considered
enormous. So programmers used every trick in the book to try to keep
their programs as tiny as possible. One trick was to avoid duplication
of code. For example, if two different parts of the program need to
calculate the cosine of an angle, then you can save precious instruction
space by writing one piece of code--a "subroutine", to use the correct
terminology--that performs the "function" (i.e., the algorithmic
calculation) desired.

Before jumping to the subroutine, however, the system needs to somehow
make note of the memory address of the instruction to which execution is
to "return" once the subroutine has finished execution. This allows the
subroutine to be called from multiple different addresses; without it,
there would be no way to continue executing the calling routine from
where it left off when it called the subroutine. This "return address"
is analagous to the return address on your mail. The meaning is
perfectly natural and existed before there were computers.

To simplify the problem of storing the return address and returning
execution to it, all but the most primitive computers have a Jump to
Subroutine and/or Branch to Subroutine machine instruction, and a
corresponding Return from Subroutine machine instruction. There is no
assembly language that I know of that has a return instruction which
returns a result. The "return" in this sense means only "return from
subroutine". To return a result, an assembly language subroutine has to
have some agreement with the caller about where to store the result so
the caller can find it.

The return instruction in BASIC and most other languages is analagous to
the machine language return instruction and probably invokes it. C and a
handful of lesser-known languages are different, and I'll deal with them
later.

So return in this sense has /*only*/ to do with the sequence of
instruction execution. It has nothing to do with "returning a result"
(see below).

Meaning #2: "yield a result"
(transitive verb)

This meaning of "return" had been used in mathematics and finance long
before computers were invented, as in "the cosine function returns..."
and "return on investment". Early computers were used almost exclusively
for scientific, mathematical, and financial computations--it was about
all they could do. These sorts of computations use the same
mathematical, financial, and actuarial functions over and over. And
that's how the terms "function" and "return"--in this sense--got into
computing. If you look up "return" in any standard dictionary of
English, you will find that one of its meanings is "yield."

As the same mathematical functions were used repeatedly, it made sense
to implement them as subroutines. And eventually, the term "function"
became used interchangeably with "subroutine" by many programmers. But
technically, a subroutine is a bit of reusable code, and a function is
an algorithm. A function may or may not be implemented as a
subroutine--it usually is, but it doesn't have to be. Conversely, a
subroutine often implements a function, but it doesn't have to.

Why C is Confusing Everyone (including me)

C is different from many other languages in that

(1) all subroutines were functions in the original language. That is,
all C subroutines return a result, or were supposed to. The compiler
would let you cheat, and the language was later modified to permit
"functions that return void"--i.e., functions that don't return a
result. But because the original implementation assumed that all
subroutines were functions, the term "function" is preferred in C. This
does /*not*/ reflect the state of affairs in other programming
languages, most of which either do not directly support functions (i.e.,
provide no built-in means of return a result) or distinguish between
functions and non-function subroutines.

(2) the return instruction has meaning #2, i.e., "return a result". This
is also unusual. Most languages either provide some other mechanism for
returning the result or leave it up to the programmer.

The return instruction in C doesn't (as a rule) directly implement
meaning #1. In most implementations, it stores the result and jumps to
the the end of the function rather than exiting the function directly.
The "return" instruction in the sense of meaning #1 is actually the
closing curly brace of the function, and before modern optimizing
compilers were invented, the generated machine code would reflect this.

In the original version of C, return was intended to specify the result
of the function in the return instruction, and in theory return should
always have a parameter. As I said, however, the compiler would let you
cheat, and people sort of assumed that return in C meant "exit the
function", especially as that's what Kernighan and Ritchie said it
meant. But it really means "set the return value and jump to the last
instruction of the function", the last instruction being the closing
curly brace.

This "set the return value and jump to the last instruction" is what
enables C to have "inline functions". These are /*not*/ subroutines, at
least not at the machine level! But the only people who probably care
are programmers and I've carried on long enough already.

Lin
--
Linda K. Sherman <linsherm -at- gte -dot- net>
Freelance Writer: Technical - Business - Government


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=