3 ms·

I've implemented a Python-inspired syntax for JavaScript which supports multi-line lambdas. This is what it looks like: http://bitbucket.org/wkornewald/pyvascr

I've implemented a Python-inspired syntax for JavaScript which supports multi-line lambdas. This is what it looks like: http://bitbucket.org/wkornewald/pyvascript/src/tip/pyvascript/stdlib.pyva#cl-30 http://bitbucket.org/wkornewald/pyvascript/src/tip/pyvascrip... It would look better with syntax highlighting, but I'm not sure if the code stays readable enough with multi-line lambdas. It also becomes more ugly once you want to use lambdas within dicts or lists: http://bitbucket.org/wkornewald/pyvascript/src/tip/tests/test.py#cl-259 http://bitbucket.org/wkornewald/pyvascript/src/tip/tests/tes... The problem here is that return x, could be either a lambda returning the tuple (x,) or the dict/list item separator, so the separator must be put on a separate line. I'm sure something like this was already proposed, so what were Guido's objections against it? I suppose it's not possible to make multi-line lambas readable enough? Maybe we need more powerful IDEs that go beyond editing text in a "stupid" text field and instead work directly on the AST and use other visual hints like boxes around functions/lambdas, etc.

wyuenho 16y ago
I just took a quick scan at PEP 318 and it seems multi-line lambdas would violate a list of design goals. * not needlessly complicate secondary support tools such as language-sensitive editors and other "toy parser tools out there [12]" * allow future compilers to optimize for decorators. With the hope of a JIT compiler for Python coming into existence at some point this tends to require the syntax for decorators to come before the function definition I'd suppose the ambiguity you mentioned above would play a role in the rejection of this syntax too. Also, there's this thing called a class decorator now. To accomplish the same thing using a prefix notation function application syntax would yield some ugly monster like this: decor(class C: def __init__(self): # 200 more lines of code... ) Bad idea. The commenter of this thread seems to think Python has acquired some bloat since the article was written, which is true but probably to a much lesser degree syntactically then some might think. If you've watch GvR's Google Talk videos on Py3k, you'd notice most of the cruft in Python 2.x is actually in the library and the data model. There are only a couple small changes to the grammar in Py3k to rectify multiple except clauses, print statements, strings and removed old style classes. Regardless, Py2.x is still a very readable language as a whole.
- silentbicycle 16y ago
  I'm talking about orthogonality, not syntactic cruft per se.

wyuenho 16y ago

I just took a quick scan at PEP 318 and it seems multi-line lambdas would violate a list of design goals. * not needlessly complicate secondary support tools such as language-sensitive editors and other "toy parser tools out there [12]" * allow future compilers to optimize for decorators. With the hope of a JIT compiler for Python coming into existence at some point this tends to require the syntax for decorators to come before the function definition I'd suppose the ambiguity you mentioned above would play a role in the rejection of this syntax too. Also, there's this thing called a class decorator now. To accomplish the same thing using a prefix notation function application syntax would yield some ugly monster like this: decor(class C: def __init__(self): # 200 more lines of code... ) Bad idea. The commenter of this thread seems to think Python has acquired some bloat since the article was written, which is true but probably to a much lesser degree syntactically then some might think. If you've watch GvR's Google Talk videos on Py3k, you'd notice most of the cruft in Python 2.x is actually in the library and the data model. There are only a couple small changes to the grammar in Py3k to rectify multiple except clauses, print statements, strings and removed old style classes. Regardless, Py2.x is still a very readable language as a whole.

silentbicycle 16y ago
I'm talking about orthogonality, not syntactic cruft per se.