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