Guido van Rossum wrote:
> 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).
Or pass it on to another function. This is something we
haven't considered -- what if one resource-acquision-
generator (RAG?) wants to delegate to another RAG?
With normal generators, one can always use the pattern
for x in sub_generator(some_args):
yield x
But that clearly isn't going to work if the generators
involved are RAGs, because the exceptions passed in
are going to be raised at the point of the yield in
the outer RAG, and the inner RAG isn't going to get
finalized (assuming the for-loop doesn't participate
in the finalization protocol).
To get the finalization right, the inner generator
needs to be invoked as a RAG, too:
block sub_generator(some_args):
yield
But PEP 340 doesn't say what happens when the block
contains a yield.
A thunk implementation wouldn't have any problem with
this, since the thunk can be passed down any number of
levels before being called, and any exceptions raised
in it will be propagated back up through all of them.
> 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.
Urg, you're right. Unless return is turned into an
exception in that case. And then I suppose break and
return (and yield?) will have to follow suit.
I'm just trying to think how Smalltalk handles this,
since it must have a similar problem, but I can't
remember the details.
> every
> local variable used or set in the thunk would have to become a 'cell'
> . Cells
> slow down access somewhat compared to regular local variables.
True, but is the difference all that great? It's
just one more C-level indirection, isn't it?
> we'll want variables
> *assigned to* by the thunk also to be shared with the containing
> function,
Agreed. We'd need to add a STORE_CELL bytecode or
something for this.
--
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg.ewing at canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4