@name

Brendan Eich brendan at mozilla.org
Thu Mar 15 09:47:34 PDT 2012


Axel Rauschmayer wrote:
>> It would be interesting (although perhaps not feasible) to do 
>> readability studies on these and other syntax matters.
>
> Very true, that would add a different quality to the discussion. But I 
> wonder if even that would change the strength with which people feel 
> (positively or negatively) about CoffeeScript-ish syntax. 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}? 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".

It's a bit of an abuse of an existing keyword. It helps to have a 
keyword in front, but not any keyword. Rather "fn" but will that really 
win adoption given the "function" legacy.

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.

/be


More information about the es-discuss mailing list