Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

Mike Samuel mikesamuel at gmail.com
Thu Jun 30 20:56:18 PDT 2011


2011/6/30 Brendan Eich <brendan at mozilla.com>:
> On Jun 30, 2011, at 6:32 PM, Mike Samuel wrote:
>
> 2011/6/28 Brendan Eich <brendan at mozilla.com>:
> No, remember I wrote "We'd still need the [lookahead ∉
> {{, function}] restriction in ExpressionStatement."

Ok, then by this redefinition of Block,
    if (foo()) {}
is not a valid program because it is not possible for a Block to not
contain any statements.  Neither UnlabeledStatementFirstList nor
WellLabeledStatement match the empty string.

> That's not true if the {} in statement context were an expression whose
> result was discarded. In such an event (without the lookahead restriction
> and with some other restriction to disambiguate away from block-as-statement
> to block-as-expression), the completion value would differ from in ECMA-262
> as it is, and eval or an embedding (javascript: URLs, e.g.) could tell.
> But that empty block else clause is not a block-as-expression: it's a
> block-as-statement, so same semantics as in ECMA-262 as-is.

Ah, I completely forgot the completion value.
Yes.
    typeof eval("if (true) {}") === "object"
would distinguish.


More information about the es-discuss mailing list