Generarl programming question.

[Thomas 'PointedEars' Lahn]

Terry Reedy wrote:

> On 4/11/2015 12:23 PM, Thomas 'PointedEars' Lahn wrote:
>> Chris Angelico wrote:
>>> The 'x' inside each function is completely separate, no matter how
>>> many times they get called. They're usually stored on something called
>>> a "call stack" - you put another sheet of paper on top of the stack
>>> every time you call a function, local variables are all written on
>>> that paper, and when you return from a function, you discard the top
>>> sheet and see what's underneath.
>>
>> Thank you for that description; I shall use it from now on when teaching
>> laymen about the call stack.
> 
> What Chris is describing is one local namespace (sheet of paper) per
> function *call*.

I *know* what he is describing: the *call* stack.

> In early Fortran (at least the first version I used),
> there was one local namespace (sheet) per *function*.

The names in such namespaces are now called static variables.  AFAIK, Python 
does not have them, but PHP, for example, has:

  function foo ()
  {
    static $bar = 1;
    $bar *= 2;
    return $bar;
  }

The variable $bar then keeps its last value for subsequent calls of foo().

> The call stack was a stack of (pointers to) functions.

It would appear that the commonly used definition of “call stack” has 
considerably changed since then, since I have been programming computers for 
more than two decades now (not including FORTRAN, though) and never heard of
your definition before.

> It has been proposed that Python use a hybrid model.  Function objects 

Interesting.  I did not know that functions are objects in Python, too.

> would have space for local variables for the first call, but there would 
> also be a mechanism to allocate additional 'sheets' for recursive calls. 
>   The idea is that most functions are not called recursively, so the 
> overhead of allocating and freeing the per-call space is usually not 
> needed.  I do not believe that anyone has implemented the idea to test 
> feasibility and the actual speedup in relation to the additional 
> complexity.

ISTM that such static variables are the remains of non-object-oriented 
programming.  In a language where functions are first-class objects, you 
would use a closure instead.  And in OOP you would solve the problem with an 
object holding the value in a property that survives exiting the execution 
context of the function/method.  It is not a good idea to reintroduce 
obsolete concepts into Python.
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.