[Samuele]
an alternative (if parseable, I have not fully thought about that) would be to leave out the KEYW-TO-BE and try to parse directly
kind name [ '(' expr,... ')' ] [ maybe [] extended syntax ]:
where kind could be any general expr or better only a qualified name that are NOT keywords, so we would possible have:
property foo: <suite>
interface.interface I(J,K): <suite>
all working as specified like 'class' and with its scope rules.
The problem is that this is much harder for the LL(1) parser; otherwise I like it fine. The name being defined (foo and I above) would be available to the code implementing 'kind', which is useful. What's still missing is a way to add formal parameters to the thunk -- I presume that J and K are evaluated before interface.interface is called. The thunk syntax could be extended to allow this; maybe this can too. E.g.: e:(x, y): S would create a thunk with two formal parameters, x and y; and when e calls the thunk, it has to call it with two arguments which will be placed in x and y. But this is a half-baked idea, and the syntax I show here is ambiguous.
Control flow statements would still have to be added to the language one by one (I find that ok and pythonic).
I disagree; there's a number of abstractions like synchronized that would be very useful to have.
Also because specifying and implementing implicit thunk with proper scoping and non-local return etc does not (to me) seem worth the complication.
See my other post.
About extending or generalizing function 'def' beyond [] extended syntax, I don't see a compelling case.
Me neither. --Guido van Rossum (home page: http://www.python.org/~guido/)