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

[Brendan Eich]

On Mar 20, 2007, at 4:38 PM, Jeff Dyer wrote:

> The => is a deal breaker for me. It looks foreign in the context of  
> the
> function keyword.

Yeah, having let or function *and* the => is a bit much (but I still  
recall you wanting = at first in the same role for expression  
closures ;-).

As Lars points out it requires bottom up parsing or a trivial mod to  
formal top-down parsing to cope. But we have other such syntactic  
exceptions to our top-down C-like heritage. I'm not sure this should  
matter.

>> Note I'm not opposed to punctuation / special syntax in general; the
>> object/array initializers are obviously better than their more
>> "general" counterparts.  I'm just not convinced that that's the case
>> for function expressions, which are already quite succinct in ES3.
>
> Let expressions strengthen the case for statement-less function
> expressions. But let's be clear, both new forms exist for aesthetics
> only. They do nothing that isn't already being done by ES3 function
> expressions.

It's not just aesthetics. Aesthetics is the science of beauty, but  
usability is what users grok -- not always what is beautiful. IOW,  
the pile of "function" keywords in the Y combinator:

function Y(le) {
     return function (f) {
         return f(f);
     }(function (f) {
         return le(function (x) {
             return f(f)(x);
         });
     });
}

may be both ugly and unusable, scaled to higher degree of lambda  
usage. We can make it prettier by supporting expression closures as  
proposed (no { return and } noise), and more usable. But would it be  
perhaps most usable, even if uglier by some tastes, to use syntax  
such as => instead of the leading function?

/be