[Python-Dev] Anonymous blocks: Thunks or iterators?

[Brian Sabbey]

Guido van Rossum wrote:
> Even without a block-statement, these two changes make yield look a
> lot like invoking a thunk -- but it's more efficient, since calling
> yield doesn't create a frame.

I like PEP 340 a lot, probably as much or more than any thunk ideas I've 
seen.  But I want to defend thunks here a little.

It is possible to implement thunks without them creating their own frame. 
They can reuse the frame of the surrounding function.  So a new frame does 
not need to be created when the thunk is called, and, much like with a 
yield statement, the frame is not taken down when the thunk completes 
running.  The implementation just needs to take care to save and restore 
members of the frame that get clobbered when the thunk is running.

Cells would of course not be required if the thunk does not create its own 
frame.

> The main advantage of thunks that I can see is that you can save the
> thunk for later, like a callback for a button widget (the thunk then
> becomes a closure). You can't use a yield-based block for that (except
> in Ruby, which uses yield syntax with a thunk-based implementation).
> But I have to say that I almost see this as an advantage: I think I'd
> be slightly uncomfortable seeing a block and not knowing whether it
> will be executed in the normal control flow or later. Defining an
> explicit nested function for that purpose doesn't have this problem
> for me, because I already know that the 'def' keyword means its body
> is executed later.

I would also be uncomfortable if the thunk could be called at a later 
time.  This can be disallowed by raising an exception if such an attempt 
is made.

Such a restriction would not be completely arbitrary.  One consequence of 
having the thunk borrow its surrounding function's frame is that it does 
not make much sense, implementationally speaking, to allow the thunk to be 
called at a later time (although I do realize that "it's difficult to 
implement" is not a good argument for anything).

> The other problem with thunks is that once we think of them as the
> anonymous functions they are, we're pretty much forced to say that a
> return statement in a thunk returns from the thunk rather than from
> the containing function. Doing it any other way would cause major
> weirdness when the thunk were to survive its containing function as a
> closure (perhaps continuations would help, but I'm not about to go
> there :-).

If it is accepted that the thunk won't be callable at a later time, then I 
think it would seem normal that a return statement would return from the 
surrounding function.


-Brian