block-lambda revival

Axel Rauschmayer axel at
Thu Jun 23 23:10:08 PDT 2011

I agree. Furthermore, it seems like newbies would automatically do the right thing with lambdas, whereas with functions, they would have to think about lexical versus dynamic |this| which everyone that I have explained it to so far had difficulty with.

I hope I’m not repeating myself, but if the following rule of thumb holds, block lambdas do indeed offer a simple way of always doing the right thing:

- Methods: dynamic |this|.
- All other functions (callbacks, custom control/looping constructs, etc.): lexical |this|.

Then you can just tell newbies the following best practice:
- Methods => use object literals (where the function operator disappears thanks to Allen’s proposal) => needed for |super|, anyway
- Everywhere else: use block lambdas

If, on the other hand, you know what you are doing, you can always fall back to old-style functions.

> From: "Mark S. Miller" <erights at>
> Date: June 24, 2011 6:49:44 GMT+02:00
> Subject: Re: block-lambda revival
> On Thu, Jun 23, 2011 at 6:44 PM, Brendan Eich <brendan at> wrote:
> On Jun 23, 2011, at 5:16 PM, Mark S. Miller wrote:
> > Arrow functions:
> >
> >     keys: function() {
> >       return this.getOwnPropertyNames().filter(
> >         (name) -> this.getOwnPropertyDescriptor(name).enumerable );
> >     }
> This is not giving arrow functions their due, though. Just use => and all is well.
> [...]
> > As fallible programmers, we can only afford a more compact function notation for defining functions with lexical "this" -- like block lambdas.
> Or =>?
> I'm leaning toward block lambdas myself, but I feel the need to play umpire here a bit -- arrows need fair play including =>, not just ->.
> Hi Brendan, I appreciate the umpire role. You do it well.
> I had indeed forgotten that => was part of the arrow function proposal. This does make it much less likely that Tom would have made the mistake if he'd been programming in JS-with-arrow-functions. But my real point is, if he had made the mistake using "->", would we have been more or less likely to catch it than in the code he wrote using "function"?
> When we talk about syntax, we often focus on the difficultly of writing code, somewhat on the hazards of writing code correctly, and on the difficulty of reading and comprehending correct code. What this thread clarified for me is how little we talk about syntax's influence on our ability to spot problems when reading code, and that we need to focus on that more.  
> Presently in JS, when seeing a "this", to understand what it means, the eye needs to scan backwards for the closest enclosing occurrence of "function" as a keyword. As this example shows, even this is accident prone. If we introduce multiple special forms that can introduce a this-rebinding boundary, where the new ones are easily missed, we make this burden worse. Is "->" easily missed? (I would guess so.) And if it is, what are we getting in exchange, and is it worth it?

Dr. Axel Rauschmayer

axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list