arrow syntax unnecessary and the idea that "function" is too long

[Brendan Eich]

On May 10, 2011, at 4:27 PM, Isaac Schlueter wrote:

> On Tue, May 10, 2011 at 16:22, Oliver Hunt <oliver at apple.com> wrote:
>> \ is a much more common lambda symbol in many languages, and i'm not sure what the ambiguity would be in \{...} or \(...){...}.
> 
> \(a,b,c) { a + b * c }
> 
> That's cute.

Oliver still has a crush on Haskell.

I've mooted \ along with ƒ, etc. for a while. \ is bad for readability because it's visually light, but worse, if we want named function expression shorthand, then \u10A0(){} is a valid Unicode-identifier-char-named function expression.

Last time we talked about \ in TC39 for shorter function syntax it died hard, IIRC.


>> I'm also really not happy with the concept of minor variances in syntax having such dramatic impact the language semantics.  All the fiddling with |this| dramatically increases the complexity of the language, it doesn't simplify it.
> 
> I completely agree.  It think any short-form function syntax should
> have the exact same semantics as the existing long-form.  We've got
> .bind(obj).  That's enough.

No, there are more efficient ways to implement something with dedicated syntax, such as CoffeeScript's =>, and it comes up enough that '.bind(this)', ignoring optimization difficulty, is too much.

The long-standing way to code lexical this is 'var self = this; ... function (...) {... self ... }'. That won't go away, but it is also crying for a shorthand.

What makes 'var self = this;' particularly bad is when the inner function is named, and all its calls are via that unqualified name.

In such a scenario, ES5 strict's rule of binding |this| to undefined just wastes the |this| parameter, and requires 'var self = this' or '.bind(this)' as heavyweight workarounds.

/be