From: "Samuele Pedroni" <pedronis@bluewin.ch>
I do worry that if my thunks are to be maximally useful, they may end up having all variables bound through "cells" (as used for nested scopes) which may give them a reputation of being slow compared to in-line code, which would limit their popularity for control flow statements like synchronized().
yes, that worries me to, it seems at least a likely source of recurring comp.lang.python threads
'with' syntax does not share the problem, because it is just syntax-sugar for a try-finally, not involving thunks. Repeating myself, unless one considers the most extreme proposals that border macros, thunks [smalltalk-ish anonymous blocks] are quite a non-orthogonal addition for a language already with functions and closures, generators and 'for'. [I leave aside generalizing 'class', which is something useful but not about control-flow statements and for me a separate problem] Much of what: do beh(args): (x,...): suite can do, can be done already with for x,.. in behgen(args): # behgen is a generator that yields where beh would invoke the thunk suite What is not covered is: 1) the case where the thunk passes back some result on invocation by beh using the proposed 'value' direct-to-caller-return statement. 2) the case where beh returns a useful value do e = beh(args): (x,...): suite Both could be adressed with the following similar syntax-sugar but that defines a usual function instead of a thunk: fdo [e=] beh(args): [(x,...):] suite # can contain return would be sugar for (or something similar): def <anonymous>(x,...): suite [e = ] beh(args)(<anonymous>) In this case we don't need to devise new rules for what 'break','continue','return' do in the suite. The suite is just the body of an anonymous function, 'return' has the usual meaning for a function in there. No new concept and rules would be added to the language. Obviously the suite cannot rebind locals in the surrounding function. Given the functional flavor of the construct especially if there's an assigmnent e = or beh uses values produced by the suite, this can be considered a feature. The addition of 'with' and 'for' plus generators would cover the other cases! OTOH what 'return' does in the suite and the fact that the suite is not an inline suite can be ambigous at first glance. It is for sure a kind of wart. But this would counterbalance the problem of defining/implementing thunks, and what 'break','continue','return' would do exactly in them, and the necessity to add 'value' to get full expressivity for thunks.