return when desugaring to closures

Dave Herman dherman at
Sat Oct 11 16:05:30 PDT 2008

Read the proposal again: the statement form of lambdas *does* return  
the value of its last expression; this is what ES3 calls the  
"completion value."


On Oct 11, 2008, at 7:02 PM, Mark S. Miller wrote:

> On Sat, Oct 11, 2008 at 3:26 PM, Brendan Eich <brendan at>  
> wrote:
>> Of course, let expressions would need lambda-coding no matter what
>> names were shadowed. The experience gained in JS1.7+ shows more let
>> block usage than let expression, but expression temporaries (lacking
>> macros and ignoring automatically generated code) are uncommon in
>> today's JS. The function-expression-immediately-applied cliché  
>> usually
>> has statements for effect, if not a return -- not a single expression
>> in its body.
> Here's an odd idea. (I'm not yet advocating this; just brainstorming)
> What if the body of a lambda were always a block (curlies enclosing a
> statement list), but, by analogy to eval, if the last statement
> executed is an expression statement, then invoking the lambda returns
> the value of that last expression statement. Let's say, further, that
> a lambda's parameter list is syntactically optional. Together, this
> would result in
>    lambda{ .... }
> being a first-class control-flow block as in Smalltalk. Then, if we
> did want let-blocks that desugar to lambda, with no additional
> complexity, a let block could be an expression even though its body
> had statements. One construct would serve both as let expressions and
> let blocks, and would "for free" turn JavaScript into an expression
> language.
>    3 + let{ while(...){...}; 4; }
> would either not terminate or evaluate to 7. None of this would  
> violate TC.
> -- 
>    Cheers,
>    --MarkM
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at

More information about the Es-discuss mailing list