Guido:
I happen to like generalized thunks because they remind me of Ruby blocks. But I realize there are more ways to skin this cat.
Seems to me it's more a case of there being several different animals we're considering skinning, and we're trying to find one tool to skin them all, and in the darkness find them... oops, sorry, mixing a metaphor with an allusion... Anyway, I think I agree with the comment made earlier that maybe we're trying to unify too many things. All of these things seem like they would benefit from some kind of code-block mechanism, but have differing namespace requirements. Let's see if I can categorise them: * Defining a function: The code block executes in a new optimised local namespace. The local namespace is discarded when the block returns. * Defining a class: The code block executes with a new dictionary as its local namespace. The local namespace is retained when the block returns. * Defining a property: Same as defining a class. * New control structures: The code block does not have a local namespace of its own, but shares one with the surrounding code. So there appear to be at least two, and possibly three, different ways that the code block will need to be compiled, depending on its intended usage. Therefore, the intended usage will have to be made known somehow at compile time. David Goodger's solution to this is to have the compiler treat each "as xxx" as a special case. I can understand Gudio wanting something more general than this. But it looks to me at the moment like we're going to need about three different syntaxes, one for each of the above code block usages. (1) We already have one for defining a function: def foo(args): ... We just have to be clear that this is *not* equivalent to any instance of (2) below, because the thunk usage is different. (2) Class-definition-like usages: def foo as something: ... Defining a class could be a special case of this, e.g. def myclass as type: ... I can understand Guido's reluctance to re-use "def" for this, given that (1) is not a special case of it. But I haven't thought of anything better yet. The best I've come up with so far is namespace foo(something): ... with "namespace" being a new keyword. For example, a property would be defined with namespace foo(property): ... But I don't like it much myself for various reasons: it's too verbose, and it wouldn't really sound right calling a property a namespace (it's not, the namespace would only be an implementation detail of the mechanism of it's creation). (3) Control-structure-like usages: expression: ... var = expression: ... Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+