return when desugaring to closures

Mark S. Miller erights at
Sat Oct 11 16:02:46 PDT 2008

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

    3 + let{ while(...){...}; 4; }

would either not terminate or evaluate to 7. None of this would violate TC.


More information about the Es-discuss mailing list