In article <GOmwp.13554$vp.9...@newsfe14.iad>
harrismh777 <harrismh...@charter.net> wrote:
>There may be some language somewhere that does pass-by-reference which
>is not implemented under the hood as pointers, but I can't think of
>any... 'cause like I've been saying, way down under the hood, we only
>have direct and indirect memory addressing in today's processors. EOS.
There have been Fortran compilers that implemented modification of
variables via "value-result" rather than "by-reference".
This is perhaps best illustrated by some code fragments:
SUBROUTINE FOO(X, Y)
INTEGER X, Y
...
X = 3
Y = 4
RETURN
SUBROUTINE BAR(A)
FOO(A, 0)
RETURN
might compile to the equivalent of the following C code:
void foo(int *x0, int *y0) {
int x = *x0, y = *y0;
...
*x0 = x;
*y0 = y;
}
void bar(int *a0) {
int a = *a0;
int temp = 0;
foo(&a, &temp);
*a0 = a;
}
In order to allow both by-reference and value-result, Fortran
forbids the programmer to peek at the machinery. That is, the
following complete program is invalid:
SUBROUTINE PEEK(X)
INTEGER X, GOTCHA
COMMON /BLOCK/ GOTCHA
PRINT *, 'INITIALLY GOTCHA = ', GOTCHA
X = 4
PRINT *, 'AFTER X=4 GOTCHA = ', GOTCHA
RETURN
PROGRAM MAIN
INTEGER GOTCHA
COMMON /BLOCK/ GOTCHA
GOTCHA = 3
PEEK(GOTCHA)
PRINT *, 'FINALLY GOTCHA = ', GOTCHA
STOP
END
(It has been so long since I used Fortran that the above may not
be quite right in ways other than the one intended. Please forgive
small errors. :-) )
The trick in "subroutine peek" is that it refers to both a "global
variable" (in Fortran, simulated with a common block) and a "dummy
variable" (as it is termed in Fortran) -- the parameter that aliases
the global variable -- in such a way that we can see *when* the
change happens. If "gotcha" starts out set to 3, remains 3 after
assignment to x, and changes to 4 after peek() returns, then peek()
effectively used value-result to change the parameter. If, on the
other hand, "gotcha" became 4 immediately after the assignment to
x, then peek() effectively used by-reference.
The key take-away here is not so much the trick by which we "peeked
inside" the implementation (although peeking *is* useful in solving
the "murder mystery" we have after some program aborts with a
core-dump or what-have-you), but rather the fact that the Fortran
language proper forbids us from peeking at all. By forbidding it
-- by making the program illegal -- the language provide implementors
the freedom to use *either* by-reference or value-result. All
valid Fortran programs behave identically under either kind of
implementation.
Like it or not, Python has similar "defined as undefined" grey
areas: one is not promised, for instance, whether the "is" operator
is always True for small integers that are equal (although it is
in CPython), nor when __del__ is called (if ever), and so on. As
with the Python-named-Monty, we have "rigidly defined areas of
doubt and uncertainty". These exist for good reasons: to allow
different implementations.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
--
http://mail.python.org/mailman/listinfo/python-list
