pre-PEP: Simple Thunks

[Brian Sabbey]

Leif K-Brooks wrote:
> Brian Sabbey wrote:
>> Thunk statements contain a new keyword, 'do', as in the example below. The 
>> body of the thunk is the suite in the 'do' statement; it gets passed to the 
>> function appearing next to 'do'. The thunk gets inserted as the first 
>> argument to the function, reminiscent of the way 'self' is inserted as the 
>> first argument to methods.
>
> It would probably make more sense to pass the thunk as the last argument, not 
> as the first. That would make it easier to create functions with optional 
> thunks, as in:
>
> def print_nums(start, end, thunk=None):
>    for num in xrange(start, end+1):
>        if thunk is not None:
>            num = thunk(num)
>        print num
>
> print_nums(1, 3) # prints 1, 2, 3
>
> do num print_nums(1, 3): # prints 2, 4, 6
>    continue num * 2

That seems like a good idea to me.

I suppose it also makes sense to have the thunk last because it appears 
after all the other arguments in the function call.

>> Because thunks blend into their environment, a thunk cannot be used after 
>> its surrounding 'do' statement has finished
>
> Why? Ordinary functions don't have that restriction:
>
>>>> def foo():
> ...     x = 1
> ...     def bar():
> ...         return x
> ...     return bar
> ...
>>>> foo()()
> 1
>

Thunks, as I implemented them, don't create a closure.  I believe that 
creating a closure will require a performance penalty.  Since one use of 
thunks is in loops, it seems that their performance may often be 
important.

I believe that saving the thunk and calling it a later time is a somewhat 
hackish way to use thunks.  Explicitly defining a function (perhaps with a 
suite-based keyword :) ) seems to me to be a more readable way to go.

But, yes, it is an arbitrary restriction.  If it turns out that 
performance isn't really affected by creating a closure, or that 
performance doesn't matter as much as I think it does, then this 
restriction could be lifted.

-Brian