I'm confused. You & Samuele both sometimes have a rhetorical style that leaves me with no idea of the point you're trying to make.
Please say it outright.
is this the reason why you have not given much feedback on my "rants"?
No, this time your rants were quite clear (at least the second time around). I need to have time to read all feedback again and think about it.
for example do you agree or disagree that it bad to have scoping rules for some piece of code that depend on some user code somewhere else and that can sometime be quite ambiguous at first glance? Thus the 'class'-like scoping rules case should be syntactically distinguishable from the inline-suite-like case?
I haven't made up my mind on that yet. It appears that the scope of a block in Ruby is quite ambiguous, yet it seems to work there. What are the scope rules for blocks passed into method calls in Smalltalk? I hope that if this feature is used in a fairly stylized way, where usually the function used to lead into the block is a well-known function, the varying scope rules may not be a problem. Many users have only a vague notion of the difference between a syntactic construct and a function (witness repeated suggestions here and elsewhere that confuse these matters), yet nobody has a problem with understanding the difference in scope rules between 'def' and 'if' statements, for example. So I hope that learning that some functions treat a thunk's scope different than others is no huge burden. In some Lisps, I believe a function can determine whether its arguments are evaluated before the call (== normal Python semantics) or whether they are somehow (I don't know the details!) passed to the function as parse trees so the function can evaluate them at will. This does not seem to confuse Lisp users. Or does it? I honestly don't know if this is popular or considered a wart. 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(). --Guido van Rossum (home page: http://www.python.org/~guido/)