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

Jeff Dyer jodyer at adobe.com
Tue Mar 20 18:44:51 PDT 2007


> From: lars.t.hansen at gmail.com [mailto:lars.t.hansen at gmail.com] On
Behalf
> Of Lars T Hansen
> Sent: Tuesday, March 20, 2007 6:02 PM
> To: Brendan Eich
> Cc: Jeff Dyer; Dave Herman; es4-discuss at mozilla.org; Vassily
Gavrilyak;
> Yuh-Ruey Chen
> Subject: Re: Expression closures - use-cases for shortcut lambda
> syntax(blocks)
> 
> On 3/20/07, Brendan Eich <brendan at mozilla.org> wrote:
> > 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.
> 
> I've started wondering how trivial that mod actually is; the parser
> must be prepared to cope with type annotations in there:
> 
>    (a,b:int):int => a+b

Yes and as I look at the grammar with the new syntax added, it has some
ugly redundancy.

> so any paren expression will effectively be parsed twice: once to
> accumulate comma-separated possibly-annotated expressions, and a
> second time to figure it out once we know how to interpret it.  Still
> not a show-stopper, I know.
> 
> > >> 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. 

Ah, thanks for clarifying.

I think the proposed syntax loses the usability case. It is redundant,
and most users won't be able to hold enough of the grammar in their
heads to easily see its meaning when they encounter it in the wild.

> > 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?
> 
> The Y combinator is not even remotely a compelling use case  for
> ECMAScript.  ;-)  More compelling are those that have already been
> posted in this thread, and as I wrote before, I didn't find those very
> compelling either.

Sorry Vassily et al, but I'm changing my mind. We should decide finally
at the f2f tomorrow.

Jd




More information about the Es4-discuss mailing list