Expression closures - use-cases for shortcut lambda syntax(blocks)
Brendan Eich
brendan at mozilla.org
Wed Mar 21 13:13:07 PDT 2007
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
More information about the Es4-discuss
mailing list