block lambda revival

Jon Zeppieri zeppieri at
Sat May 21 16:23:58 PDT 2011

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.
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.

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.
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


More information about the es-discuss mailing list