Two questions about call-by-name

Hello all,


I have a couple of questions regarding famous (or infamous) call-by-name
parameter passing.


I understand, how thunks are compiled for each of the actual
parameters and how they are called each time, when there is an
access to the corresponding formal parameter. Nevertheless, there
are few things which aren't yet clear for me:


1. It looks like that the code of each thunk must COMPUTE AND RETURN
      BOTH THE ADDRESS AND THE VALUE OF THE ACTUAL PARAMETER
      (if it has them both, of course) OR THE COMPILER CAN'T BE A SINGLE
      PASS ONE. Let's consider the following example and assume that the
      compiler is about to generate the code for (1). At that moment it still
      "doesn't know" is there anything like the statements (2), (3), (4) and (5)
      ahead:


        PROCEDURE X(NAME a:INTEGER);
            VAR
                b:INTEGER;
            BEGIN
                . . .
                b := a + 1; (1)
                . . .
                a := b + 2; (2)
                . . .
            END X;


        . . .


        X(d); (3)
        X(c[i]); (4)
        X(f + 1); (5)


There are the following options possible:


        a. The compiler assumes that the corresponding thunk for 'a' always
              returns the value, not the address. That makes the later compilation
              of (2) impossible.


        b. The compiler assumes that the corresponding thunk always returns
              the address. That makes the compilation of (2) possible, but later
              the statement (5) must be considered illegal (an expression has no
              address). If we use this startegy then (5) remains illegal, even in the
              absence of (2).


        c. The compiler must analyze the entire body of the procedure before
              generating any code for it. If only (1) is present then thunks
              must return the value and (3), (4) and (5) all are legal. If (2) is
              present too, the compiler assumes that the corresponding thunks
              return the address and (5) is illegal. This rules out a single-pass
              compiling.


        d. The compiler uses the value in (1), but the address in (2). It
              means that later (3) and (4) are considered legal, while (5) is
              considered illegal. If (2) is absent, (3), (4) and (5) all are
              considered legal. For (3) and (4) the thunks return both address
              and value, but for (5) - only the value.


        e. The compiler assumes that the corresponding thunk always returns
              the address. For (5) the thunk computes the value of 'f + 1', then
              stores it in some memory location and provides its address.


The options a. and b. are totally unacceptable, because they are against
the semantics of most of the languages. The semantics for c. and d. is equal,
but c. can be used only in a multipass compiler. The option e. is against the
semantics of call-by-name parameter passing, because it forms an illegal
statement in the body of the procedure - 'f + 1 := b + 2'. So, only c. and d.
seem to be correct, but for a single-pass compiler only the option d. can be
used.


2. Let's consider another example:


        PROCEDURE X(NAME a:INTEGER);


            PROCEDURE Y(NAME b:INTEGER);
                VAR
                    c:INTEGER
                BEGIN
                    c := b + 5 <--- (1)
                END Y;


            BEGIN
                Y(a) <--- (2)
            END X;


        . . .


        X(k+m[n]);


        . . .


At which point, (1) or (2), the actual parameter 'k+m[n]' must be evaluated ?
According to the definition of call-by-name from Algol-60, the option (2)
seems to be correct, but I'm not sure. Option (1) looks more logical.


Could someone with an experience in implementing call-by-name parameter
passing please answer me these two questions ? Many thanks in advance.


                                                                                    Andrejs.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.