arrow function syntax simplified

Rick Waldron waldron.rick at
Wed Mar 28 10:29:45 PDT 2012

I've been championing this syntax since Dave proposed it as the "tri-lambda
syntax". Through this, I've exposed many JavaScript programmers of varying
experience (from fellow bocoupers to our JavaScript training sessions -
overhwhelmingly actionscript or ruby devs) to the three major pieces:

*Just a short hand:*
  let thin = ( a ) -> { return x; };

  The general response to this is that it makes complete sense: "just
syntax" and "just shorthand" are common "i get it now"    phrases. Also,
this is highly desirable ie. they want it now.

*Has new meaning:*
  let fatexpr = ( y ) => this.x * y;

  let fatdoexpr = ( y ) => do {
    if ( y > 10 ) {
      this.x * y;
    } else {
      this.x = 0;

  The general response to this is excitement about new possibilities, no
more foo.bind(this), no more var self = this;. The semantics and logic is
immediately obvious to the ruby devs, the rest "get it" because it looks
and acts similar to something they've seen "elsewhere" which is wide and

The only recurring confusion is why:

  let fatexpr = ( y ) => this.x * y;

Doesn't look like:

  let fatexpr = ( y ) => { this.x * y };

...Nothing to do with -> and =>, but everything to do with expecting to see
a block/function body on the right of the arrow... which the do { expr }
seems to mitigate - somehow seeing the curlies there solidifies their own
belief that the right side is what they want it to be.

And of course, I've made great use of these (apologies for the reposting)

Which has a "seeing is believing" effect.


On Wed, Mar 28, 2012 at 12:44 PM, Kevin Smith <khs4473 at> wrote:

> we need either fat arrow or block lambda based TCP preserving functions.
>>  We don't need thin arrow and we really don't need the confusion it would
>> create.
> What about situations where the user wants bound |this|, but no other TCP
> stuff?  Callbacks and a large portion of event handlers fall into this
> category.  Without supporting syntax, these use cases will either have to:
> 1) Use "=> do {}", which is heavier, and which will cause unintended
> problems (completion leak and invalid use of return).
> 2) Use "(function() {}).bind(this)" which is awkward.
> 3) Use "var self = this; function() {}" which is also awkward.
> kevin
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list