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

[Brendan Eich]

On Mar 21, 2007, at 3:26 AM, Igor Bukanov wrote:

> Yet Y combinator is a useful boundary case to test syntax proposals
> that in fact caused me to cool for the proposal. Here are the
> alternatives:
>
[...]
> function selfApply(f) f(f)
>
> which gives for the combinator:
>
> function(le) selfApply(function(f) le(function(x) f(f)(x)))
>
> le => selfApply(f => le(x => f(f)(x)))
>
> Now the "=>" case does not look that much better and in fact I suspect
> that to comprehend the code it can be worse than using function
> keyword since an explicit and long keyword gives a useful reference
> indeed.
>
> The bottom line: "=>" allows to create incomprehensible but nicely
> looking code yet for simpler down-to earth cases its advantages are
> minor if any.

I agree (nice demonstration based on Y -- thanks!). I'm quite cool to  
=> now, and I'd like to point out that with expression closures as  
proposed, the only issue that nags at us, the one Vassily raised  
obliquely, is the cost of the leading 'function'.

I agree the top-down parse-ability of (a,b,c) => expr is poor. Lars  
makes a good point about have to check the AST. I pointed out that we  
have a similar case with destructuring assignment (but not  
destructuring in declarative binding contexts). But two wrongs...

If we had proper macros, we could support |define λ function| and be  
done. As Peter Hall points out, λ is a perfectly valid ES3  
identifier. The one could rewrite:

function(le) (function(f) f(f))(function(f) le(function(x) f(f)(x)))

as:

λ(le) (λ(f) f(f))(λ(f) le(λ(x) f(f)(x)))

which looks awfully familiar. But that can wait for ES6 ;-).

/be