Kevin Smith wrote:
Knuth. Respect.
For sure - LR parsing still blows my mind (looks for his trusty dragon
book - here it is!).
We could do that and leave the arrow-free form with unbound
|this|. Better by my argument that anything based on today's
function body-plan should not start adding TCP conformance -- need
new (fat arrow if not freaky-deaky) syntax for new semantics (some
or all of TCP).
I agree and think that fat arrows should indicate bound this wherever
fat arrows appear.
=> bound this
{ |x, y| } bound this, TCP control semantics, etc...
I'm not sold on the utility of block lambdas (because it's all gone
async these days) but fat arrows would be immediately useful to me.
"var self = this" no more...
I originally wrote up
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
and
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
as mutually exclusive alternatives, but changed the framing for the
latter to recognize the new semantics (beyond =>'s |this| TCP
conformance). Yet I agree that if we get shorter function syntax
together, block-lambdas lose some of their "oomph".
For downward funargs called by the control flow, and so for novel
control structures, with paren-free call affordances even, they still
have some win. Perhaps not enough to make it into any future edition
without prototyping in popular engines and grass roots pressure...
Anyway, I'm still trying to get something for shorter function syntax
into ES6. I think TC39 can yet make an exception if we have our
validation story figured out. That is where to focus fire.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
