lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

Brian Hagerty wrote:
The call frame typically contains additional caller context (over and above the list of incoming argument references), and that caller context typically includes the calling object's identity or handle, and possibly a return address (among other things). 

Yes, but it might not be the frame you think it is (see below).
But I didn't suggest using the return address or instruction pointer in my discussion of how Lua might implement "self" references in function bodies. -- I mentioned that the call frame typically contains a reference / identity / handle of the calling object that Lua might use. Thus, in your example ... 


function foo(a)
  -- 'a' is an Account object
  a.deposit(5)
end
The return address, as far as 'deposit' is concerned, points to the
instruction after the a.deposit(5) statement (which would be a return, I
suppose). The return address, for 'deposit', is not the table 'a'.


What then if it were:

function pay_debt(debts)
  local b = most_urgent(debts)
  return b:deposit(5)
end

(which by the way, could just as well be written:

function pay_debt(debts) return most_urgent(debts):deposit(5) end

)

Since Lua does tail-calls properly, the upwards call frame during the
execution of b:deposit is the caller of pay_debts, not the frame created to execute pay_debts itself.
... the call frame for the call to deposit already contains the identity (object/table reference) of "a" (over and above any arguments that also get pushed on the stack).
Not necessarily, see the condensed version of the function above. In that case (as with colon-chained calls), the target object for the colon call is a temporary and does not need to be retained on the stack. 
>...
And therefore within the body of the deposit function / method, any reference to "self" could be implemented as a reference to the immediate caller "a" stored in the call frame -- i.e. without the need to use self arguments in the call or self parameters in the definition.
That would be a severe restriction on function calling which would be less than orthogonal to other language features, in my opinion.