>> I think that CS has a syntactic style that is quite different from JS
>> (probably for the better, just imagine how confusing things would be once
>> ES6 is in wider use...). That’s why I’m not sure that mixing the two styles
>> is a good idea. And that’s why I prefer Allen’s proposal over arrow syntax.
>
> You mean do (params) {stmts}?
Yes: https://gist.github.com/2015544
> The objection there (from dherman and me at least) is that "do" means
> immediately-invoke as in do expressions, IIFE sugar (CoffeeScript's do,
> useful for capturing var bindings in a loop), and Smalltalk do: selectors. It
> does not mean "defer" -- "do later".
The way I interpret the syntax for me is: Adding parameters to a block delays
its execution (loosely like quoting in Lisp).
> Jeremy Ashkenas tweeted “For the record, I too favor [block lambdas] if
> arrows in JS will need curlies to delimit blocks. Curlies or arrows, not
> both.” This is another blow (I mentioned two yesterday) against
>
> (params) -> {stmts}
>
> If we *only* add
>
> (params) => assign-expr
>
> and put this at the AssignmentExpression level in the grammar, then we almost
> have consensus. The remaining issue is agreeing that (expr) covers (params),
> forever. I'm hopeful we'll manage to reach consensus there.
>
> Then the (separate) do-expression strawman, with full TCP, composes fairly
> nicely (four chars linkage):
>
> (params) => do {stmts}
>
> The lack of unbound-this and non-TCP function body, i.e., the lack of
> thin-arrow, means users have to reach for plain-old-function still. This may
> be ok. Kevin's numbers say ~10% cohort.
>
> Fat-arrow-only (plus do-expressions) looks like the minimal and likely winner.
Given that TCP support is something new, the above looks and feels OK. Should
grammar complexity be an obstacle, we still have block lambdas and Allen’s
proposal.
Two things I feel strongly about:
1. Don’t introduce another way of defining current functions (apart from `fn`).
The combination of abbreviated method syntax in object initializers,
TCP/implicit return “blocks” and `fn` should be enough.
2. Don’t introduce two kinds of arrows to distinguish between lexical and
dynamic `this`. Currently, things are very confusing to newbies. Either the
solution you mention above or what Allen proposes would help tremendously,
because people would automatically do the right thing. With two arrows, code
written by experts would become hard to understand for newbies.
Axel
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
