Expression closures - use-cases for shortcut lambda syntax(blocks)

[Brendan Eich]

On Mar 19, 2007, at 1:59 PM, Jeff Dyer wrote:

> To be consistent with the current expression form
>
>     function id (x) { return x }
>
> should be shortened to
>
>     function id(x) x
>
> not
>
>     function id(x) => x

Your argument is not consistency, but brevity: "because the latter  
erase characters from the current function expression form, while the  
former adds '=>'". A different consistency argument, with the new  
lambda syntax, favors =>.

How to decide between conflicting consistencies and brevity? One role  
of syntax is to catch the reader's eye and make plain what may be  
hard to see or visually acquire quickly. In this light, => is good  
and we would not do without it, or shorten it, for the new lambda  
syntax.

Lars and I have written a fair amount (Lars did most ;-) of the  
builtins/*.es self-hosted standard library (ECMA-262 Edition 3  
Chapter 15) may agree (I hope) that just

function (formals) expression

has been less readable than I think they should be. Stylistically, we  
have always written

   function (formals)
     expression;

in classes. Note the semicolon, which was not originally required by  
the grammar. We've been loath to put both head and body on one line  
because the closing formals) may be hard to see as distinct from the  
expression. Anyway, I'd like to hear Lars's preference, but I don't  
think consistency favors one outcome, and brevity can't always win  
(we're talking JS here, not C/C++/Java/C#).

/be