Block lambda is cool, its syntax isn't

Brendan Eich brendan at
Sat Jan 21 11:50:31 PST 2012

> François REMY <mailto:fremycompany_pub at>
> January 21, 2012 2:14 AM
> function a(x) {
>    let count=0;
>    let arr = [...];
>    let $lambda = {
>        [Call]: {||
>            ...
>        }
>    };
>    arr.forEach($lambda);
>    $lambda.[Call] = function() { throw new InvalidTargetException(); }

No, we are not specifying dynamic semantics based on a mutation to the 
[[Call]] internal property.

I wrote "When you write "it should only be allowed", are you seriously 
proposing a checkable syntax and static check of some kind?"

I was alluding to ideas such as Ruby's yield operator, which is the only 
way to name the extra downward-funarg-only block argument, preventing 
heap escape (but of course, Ruby grew & params and so on, so had to deal 
with escape anyway).

This is no static check. It is unacceptable both as semantics and in 
real implementation costs.

Again, in general a block-lambda that escapes and is called after its 
parent function activation has deactivated is not a bug. It should not 
be forbidden uncondionally. The only requirement is that control cannot 
flow back to the defunct activation. Only such attempts via 
break/continue/return will throw.


More information about the es-discuss mailing list