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

Vassily Gavrilyak gavrilyak at
Wed Mar 21 08:54:13 PDT 2007

On 3/20/07, Lars T Hansen <lth at> wrote:
> On 3/19/07, Brendan Eich <brendan at> wrote:
> > Anyway, I'd like to hear Lars's preference, but I don't
> > think consistency favors one outcome, and brevity can't always win
> > (we're talking JS here, not C/C++/Java/C#).
> gmail threading is pretty much broken so I don't quite know where all
> of this stands as of now, but for the record I pretty much loathe
> these proposals :-)
> As far as I'm concerned if it doesn't start with "function" it's a
> non-starter, because the terse syntax isn't worth the cost.  The
> brevity of anything else doesn't actually pay off (none of the
> examples posted convince me).
That's probably because you've just looked at tha
Well, that's ok.

> I'm not even sure that expression functions of the form "function (a)
> a*2" are really worth it, but at least I'll concede that we agreed to
> put those in.  I doubt it makes any difference at all whether one
> writes "function (x) 37" or "function (x) => 37"; I think they're both
> slightly inferior to "function (x) { return 37 }".
> 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.
Yes, two times longer then everything else. That's why we have no
"first-class" functions in ES. First-class means same rights, while
functions are discriminated in syntax (and only in syntax).
That's probably almost everybody knows that functions are first-class
in Ruby, and very few know this fact about ES :-)

> (Also, unless I'm mistaken something like the proposed
> "(a,b,c,d,e,f,g,h,i,j) => 37" requires arbitrary lookahead in a
> top-down parser, and I thought we were trying to avoid that.  >
I wasn't in favour of this proposal much and exactly because of lookahead.
Initially proposed haskell-like (\ it){} was free from lookahead
problem, it event wasn't in parser, but in lexer. But it is not so
pretty, I agree.
=> also plays well with typing of functional parameters (where YOU had
a pain to write and read).

> I understand it can be fixed in the same way we fix destructuring
> assignments, but it makes me uneasy, as the arbitrary lookahead is
> also required by the human reader.  At least for destructuring the
> major use cases are in binding forms, not really in plain
> assignments.)
> --lars

Please take a minute and write this simple Ruby code in ES.
Please do not refactor it, suppose we do not need any of logic from
this function anywhere else and we do not want to bloat our class with
miriads of methods.
So. just one function.

def doSomethingWithNewPeople
    selectSQL ="SELECT code, name from people where status='new'"
    insertSQL = "INSERT INTO young(name,age) values (?,?)"
    connection.transaction do |tx|
        connection.prepare(selectSQL) do |selectStatement|
            connection.prepare(insertSQL) do |insertStatement|
                selectStatement.executeQuery do |record|
                   name, age = record
                   if name ~ /.*Joe/ and  age % 2 then
                      insertStatement.execute(name, age)

More information about the Es4-discuss mailing list