block lambda revival

Brendan Eich brendan at
Sat May 21 17:54:13 PDT 2011

On May 21, 2011, at 4:23 PM, Jon Zeppieri wrote:

> On Sat, May 21, 2011 at 10:43 AM, Brendan Eich <brendan at> wrote:
>> On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
>>> On Fri, May 20, 2011 at 5:54 PM, Brendan Eich <brendan at> wrote:
>>>> An essential part of this proposal is a paren-free call syntax
>>> Why is that essential?
>> The argument, as I understand it from Smalltalk, Ruby, and E experts, is empirical, and in part a matter of intentional design: users write blocks as actual parameters to make control abstractions. Most such abstractions taking block arguments do not let those blocks escape through the heap or a return value -- the blocks are downward funargs. This aids in making new control abstractions more efficient than functions to implement, as well as more usable. Built-in control flow statements have (optionally) braced bodies that do not need parenthesization, so why should new ones created by users passing blocks?
> I like the proposal.
> I'm not sure I follow the above, though. I get the point about
> un-parenthesized blocks making for better control abstraction syntax;
> I'm just not clear on how that relates to the downward funargs point.

It doesn't. Two separate points. Sorry, I should have used a bulleted list or something :-P.

> In Ruby, for example, the anonymity of the implicit block argument
> prevents its capture and guarantees that the param is downwards-only.
> It seems unrelated to parenthesis.

Right, and we are convinced that this is an unnecessary concession in Ruby's design toward ease of implementation. Analyzing Harmony code to link uses to definitions it not hard, and arguments.callee is poisoned pill (already; ES5 strict).

An implementation that wants to optimize must do aggressive name use/def analysis, and it can readily detect escape of a funarg.

> Since the strawman only addresses the call syntax, I figure that it
> doesn't affect formal argument syntax -- I mean, that you're not
> proposing something like Ruby's implicit, anonymous, last formal.

Nope. Strawman grammar changes look complete to me. Nothing left out but the semantics. Please tell me if I'm missing something.

> Since block args would be named, and since they are first-class
> (evidenced by the examples in the strawman), I'm guessing that they
> are allowed to escape up the stack. But I may have missed something
> basic.

They can indeed escape (so can Ruby &params, but we don't have arity-mismatch error [yet] and we don't need to complicate the design as Ruby did, in its several different ways). Implementations will cope.


More information about the es-discuss mailing list