return when desugaring to closures

Brendan Eich brendan at
Thu Aug 21 11:09:22 PDT 2008

On Aug 21, 2008, at 10:50 AM, Lex Spoon wrote:

>>> (function(x, y) {
>>>   print(y);
>>> })(2, x)
>> We've been over this. What if you replace print(y) with return y?
> Desugaring to closures is highly worthwhile,


> so it looks worth solving
> these.  Defining good variable-definition semantics is hard, as the
> experience with var shows, so it's good to reuse function literals if
> at all possible.

Why do you assume function expressions (not literals in any immutable  
sense) have good variable definition semantics for their arguments?

> The problems you describe are actually not hard to fix.

I don't agree, but we'll see how Java closures work out. In the mean  

> All that has
> to happen is that return is labeled with the function it applies to.
> If at parse time no label is supplied, then the parser can manufacture
> a label to use.

Propose some unambiguous syntax, since return may have an expression  
on its right.

> So, I agree that return, etc.,


> need to be fixed up if you desugar to
> closures, but they can indeed be fixed up.  Further, you probably want
> non-local return anyway if people are going to use a lot of function
> literals in their code.

This has never in my hearing been requested, and people use lots of  
closures in JS. Experience does not back the desire here to invent  
something new, or to borrow from languages with different evaluation  

TC39 is not going to invent, so the likely outcome in Harmony is  
something actually implemented, with user feedback, with small  
adjustments also implemented at least in open-source nightly if not  
beta-tested fashion.

That's not an invitation to submit patches, btw. I'd rather have some  
agreement in the committee before trying more experiments. Mozilla  
has done a number over the years. They were worthwhile, but far from  


More information about the Es-discuss mailing list