return when desugaring to closures

David-Sarah Hopwood david.hopwood at
Thu Oct 16 17:49:18 PDT 2008

Mark S. Miller wrote:
> On Wed, Oct 15, 2008 at 4:49 PM, Dave Herman <dherman at> wrote:
>> In the grammar for proposed ES4, LetExpression was under
>> PrimaryExpression. That's where I'm suggesting LambdaExpression might
>> fit. IOW:
>> PrimaryExpression ::= ...
>>                    |  LetExpression
>>                    |  LambdaExpression
>> LetExpression ::= "let" "(" LetBindingList ")" CommaExpression
>> LambdaExpression ::= "lambda" FunctionSignature LambdaExpressionBody
> [quotes inserted above]
> As we argue about the pros and cons of this proposed
> expression-body-based grammar and similar variations, does anyone see
> any problems at all with the following block-based alternative grammar
> for them?
>   LetExpression ::= "let" ("(" LetBindingList ")")? Block
>   LambdaExpression ::= "lambda" FunctionSignature? Block

You read my mind; that is exactly what I was about to propose.

Note also that ("(" LetBindingList ")") and FunctionSignature are
almost identical, and could probably be merged. In that case

  let ... { body }

could be sugar for

  (lambda ... { body })()

if the binding of default arguments to a lambda has the same semantics
as the binding of variables in a let. (There are several reasonable
choices for that semantics; I suggest reading
<> to start with.)

The degenerate syntax "let {...}" allowed by this grammar at first-sight
doesn't seem very useful, until you realize that it has a similar effect
(apart from not preventing hoisting of 'var' declarations past the
'let') to the Crockford module pattern "(function() {...})()".

David-Sarah Hopwood

More information about the Es-discuss mailing list