David Herman wrote:
On Mar 6, 2012, at 2:37 PM, Brendan Eich wrote:
You didn't show the expression-bodied variant:
myList.map((x) x + 1)
which is even shorter, if it's doable at all (I haven't worked out a good
grammar yet).
That's actually a pretty good space to aim at, IMO. I conjecture the majority
cases where you really want the concise notation is for an expression body.
Yes, it's a sweet spot (take a look at prototypejs's use of function
expressions as parameter to inject calls, where the callback returns a
value. Almost all expression bodied, a few overlong ones that must have
a final return).
Moreover, if you wanted to do some control along with an expression, you could
use do-expressions:
myList.map((x) do { for (...) { ... } f(x) })
Note that combination (expression closures + do-expressions) brings back the
exact same expressiveness of block-lambda.
Not so, because no TCP. Only block-lambdas preserve TCP fully.
If you mean only completion-value implicit return, sure, but that's not
enough to expression the exact same things as block-lambdas.
Longer braced-body cases are where completion-leaks can hide. If you write
functional/expression-langauge-y JS then you'll be ok. If you start to write
control statements with early returns you may run into trouble.
I can believe that. Do you think do-expressions would mitigate the risk? I
suspect they might, by virtue of the explicit opt-in via the keyword at the
head.
Maybe, and I like do expressions, but it's a bit of serendipity here --
good compositionality -- not a strong selling point IMHO.
Moreover, it essentially means abandoning ever having TCP lambda.
Why?
Just because there are only so many variations on function syntax we're going
to add to the language.
Block-lambdas are not just function syntax, to repeat. They are new
semantics (TCP). They also bring other affordances (paren-free calls).
- TCP-respecting shorter function (possible return-value leak, freaks some
people out)
My point remains that TCP-anything should be delimited by new and freaky-deaky
syntax. Or else it will (ceteris paribus) result in more completion leaks or
mistargeted returns or whatever.
I hereby propose expression closures + do-expressions as the new, freaky-deaky
syntax. Thoughts?
For full TCP? I don't buy it. 'return/break/continue' from outer
function, not inner? We're discussing shorter function syntax here, so
'return' should return from the shorter (inner) function.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
