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 -- http://mail.python.org/mailman/listinfo/python-list
