Short Functions

Brendan Eich brendan at mozilla.com
Sun May 22 16:05:38 PDT 2011


On May 22, 2011, at 12:18 PM, Isaac Schlueter wrote:

> On Sat, May 21, 2011 at 23:07, Sami Samhuri <sami at samhuri.net> wrote:
>> The semantics have shortcomings though and introducing new syntax to save a
>> few keystrokes is frivolous.
> 
> Cutting out many kilobytes of code from JavaScript programs by
> streamlining the single-most commonly-used idiom is hardly frivolous.

The counterargument, I don't share it but you seem to be focused on bandwidth, is transfer-encoding compression, gzip.


> In fact, I'd argue that it should be one of the main goals of this
> list and of TC-39.

We should have short syntax as a main goal? That hits return too. It arguably means block lambdas, since they are more concise and more expressive. But you demur from them below, so brevity can't be the top "main goal".


> Adding new semantics to the language seems frivolous to me, if doing
> so does not solve problems we actually have today.  Lambda-blocks, as
> proposed currently, adds considerable surface area to the language
> without providing any real value.

Please stop asserting and generalizing. The strawman is smaller in syntax than arrow functions. The semantics reuse a lot of existing machinery and I'm not done yet. It's not fair to make unquantified assertions based on taste.

Many hackers testify to the "real value" of block-lambdas in Smalltalk, Ruby, and E. Let's not put them down by asserting only.


> The complications have not been very well explored, and are not
> trivial, in my opinion.

They have been explored in other dynamic languages. They're not that bad. But apart from my "other languages" counterpoint, which matters, we're just pushing opinions at each other.


> I am also unconvinced by the "looks like a block" argument.  The body
> of a es-current function also "looks like a block",

No. That's not the relevant comparison. The issue is whether the whole function-or-block-lambda-expression "looks like a block".

If you always write

  a.map(function (e) { return e*e; })

then of course return must mean what it has in ES1-5.

If you extend the language to support

  a.map {|e| e*e}

then the appearance of function is nowhere in evidence, so completion value as return value and 'return' returning from the outer function are possible to specify. We are not violating an expectation or principle of least surprise based on function syntax.

Indeed in a similar context, e.g.

function f(a, fail) {
  let b = [];
  for (let i = 0; i < a.length; i++) {
    let e = a[i];
    if (e === fail)
      return null;
    b.push(e*e);
  }
  return b;
}

the return in the block body of the for loop uses known syntax and semantics, the block-lambda form:

function f(a, fail) {
  return a.map {|e|
    if (e === fail)
      return null;
    e*e;
  }
}

reuses that return-in-block knowledge. Yes, the head a.map differs from a longer-winded for (;;) loop (with let b = [] etc.). That's true but it does not alter the argument about return-in-block. It just shows how much shorter the block-lambda version is, bonus.

That block-lambdas look like blocks not function expressions is pretty much the whole point. I don't think you addressed it.

Yes, block-lambdas evaluate to values so can be called later, with novel semantics coming into play to build novel programs and control abstractions. That is progress by some lights.

A reductionistic argument that we can't add any new semantics doesn't cut it. There has to be some specific downside beyond "zomg new!" I'm not saying you are reacting that way, but missing the looks-like-function-expression vs. looks-like-block point by singling out the block body of a function does not cut it.

Finally, a word on footguns. JS has some big ones, fixed in Harmony or already in ES5 strict. We cannot call Smalltalk-like blocks footguns based on the history of Smalltalk, though. Same goes for E (far fewer users, but relevant testimony from MarkM). I believe the same goes for Ruby, in spite of the messier block/proc/lambda complexities.

So where's the beef? Trepidation should be addressed by user testing. We'll do that. Meanwhile, we can consider block-lambdas for Harmony and even (I argue) for ES.next, spec'ing and prototyping to user-test as we iterate on that edition.

/be
/be


More information about the es-discuss mailing list