[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/)
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