What other languages use the same data model as Python?

Chris Torek nospam at torek.net
Fri May 6 14:17:55 EDT 2011


In article <GOmwp.13554$Vp.9996 at newsfe14.iad>
harrismh777  <harrismh777 at 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



More information about the Python-list mailing list