Short Functions

Brendan Eich brendan at
Sat May 21 18:39:37 PDT 2011

On May 21, 2011, at 6:13 PM, Alex Russell wrote:

> On May 21, 2011, at 5:56 PM, Brendan Eich wrote:
>> On May 21, 2011, at 5:28 PM, Isaac Schlueter wrote:
>>>  function (a, b, c) { return a + b * c }
>>> but I really don't want to replace our existing simple semantics.
>> Nothing is replaced.
>> You mean adding new semantics for new syntax is like replacing current semantics with current + new, which is too much?

You overcited, I'll use it as an opportunity to say that function + return are still there. If short function syntax without block semantics is wanted, then we're back to -> or # or something like that, and it only shortens 'function' -- it does not avoid 'return' because several TC39ers object to the completion value leak hazard.

Some of the objectors drop this objection with block lambdas. The reasons are that block lambdas have new syntax that favors brevity, expression body in the braces; or that using blocks to build control abstractions in a statement language does not create any completion value leak, because the block's caller ignores the completion value of the block (the block may explicitly 'return' but that returns from the enclosing function.

Anyway, there's a difference between block-lambdas and shorter function syntax that goes beyond the added semantics. Shorter function syntax will never save 6+1-or-2 (space or left paren after return. requiring right paren at end) characters, not so long as the completion value leak hazard is a worry -- and it is for functions.

>>> I see a lot of the discussions of short function syntax seeming to
>>> imply ruby-block semantics, with the "return returns from the parent"
>>> idea.  It would be great to separate those two concerns.  They are
>>> very different.  One is sugar, the other is a much more radical change
>>> to the way the language works, which I'm not altogether convinced is a
>>> good or useful thing.
>> It's essential to the control abstraction programmability. Take a look at the examples. You want those block-looking things to support Tennent's Correspondence Principle. Return from a block in JS today returns from the enclosing function. Same for return from a block-lambda in a function. It's an early error to return from global code, and will be in a block-lambda in global code.
>> Why is this so bad? JS programmers return, break, and continue from blocks all the time.
> I think you're over-playing the use of blocks in the syntactic sense.

I'm not doing anything here but asking why return from a block is ok but return from a block-lambda having the same semantics (modulo throwing in the case the block-lambda escaped and was called after the enclosing function's activation, in which the block-lambda was evaluated, has deactivated) is not ok.

> My observation has been that when people use them, it's primarily accidental. Citing that feels like weak ground to argue from.

When people use blocks meaning statement-lists in braces, it's accidental?

No, people use them to join two statements that run in order. That's how you compose for sequencing. This may be incidental to the question of block-lambdas, but it's not accidental.

Some style guides and tools even want braces around every sub-statement, even the shortest if (unlikely) { break; } consequent. That's not required by C-like languages but it actually plays well with block-lambdas, at a style or coding convention level.

Again, my point was not to argue "for" blocks. I was (pretty clearly :-/) probing why return from a block, where the return is the last statement in a necessarily-sequenced group of statements in the block, is ok; but return from a block-lambda should be different.

The possibility of block-lambdas escaping downward-funarg flows and being called later, and getting runtime exceptions due to return from a returned function activation, can't be it. Exceptions happen in dynamic languages. Changing return in a block-lambda to return from the lambda just makes a different kind of problem: that return from a block differs (loss of Tennent correspondence).

Really, we're between these choices:

1. Do nothing, function + return 4ever.

2. Shorter function syntax by some abbreviation for 'function' that still requires 'return ' followed by an expression to return a value.

3. Block-lambdas.

Some on the committee are enthusiastic about 3. 2 is warm beer and not going anywhere fast, least of all with # (a misuse of that punctuator, which is wanted for other purposes). 1 is lame.


More information about the es-discuss mailing list