<html><head><style type="text/css">body { background: rgba(255, 255, 255, 255); }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 23, 2011, at 3:27 PM, Brendan Eich wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Also, if any { block } could be a lambda, perhaps we won't need that (nor any new) syntax for block-lambdas.</div></div></blockquote><div><br></div>We would need new syntax still, for formal parameters.</div><div><br></div><div>Making blocks be expressions requires unifying the <i>ObjectLiteral</i> and <i>Block</i> productions. I don't know how to do this in without at least two-token lookeahead, and it is not a backward compatible change if done for all places where <i>Statement</i> : <i>Block</i> in the current grammar.</div></div></blockquote><br></div><div>Apologies for not crediting Breton Slivka, who suggested working this approach here:</div><div><br></div><div><a href="https://mail.mozilla.org/pipermail/es-discuss/2011-June/014933.html">https://mail.mozilla.org/pipermail/es-discuss/2011-June/014933.html</a></div><div><br></div><div>Here's an attempt to formalize the unification grammatically.</div><div><br></div><div>Block:</div><div>    { UnlabeledStatementFirstList }</div><div>    { WellLabeledStatement StatementList? }</div><div><br></div><div>UnlabeledStatementFirstList:</div><div>    UnlabeledStatement</div><div>    UnlabeledStatementFirstList Statement</div><div><br></div><div>Statement:</div><div>    UnlabeledStatement</div><div>    LabeledStatement</div><div><br></div><div>UnlabeledStatement:</div><div>    Block</div><div>    VariableStatement</div><div>    EmptyStatement</div><div>    ExpressionStatement</div><div>    ContinueStatement</div><div>    ReturnStatement</div><div>    LabelUsingStatement</div><div>    DebuggerStatement</div><div><br></div><div>LabelUsingStatement:</div><div>    IfStatement</div><div>    IterationStatement</div><div>    BreakStatement</div><div>    WithStatement</div><div>    SwitchStatement</div><div>    ThrowStatement</div><div>    TryStatement</div><div><br></div><div><div>LabeledStatement:</div><div>    Identifier : Statement</div><div><br></div><div><div>WellLabeledStatement:</div><div>    Identifier : LabelUsingStatement</div><div>    Identifier : WellLabeledStatement</div><div><br></div></div></div><div>(I'm using the American spelling of "labeled" and "unlabeled". Can't help myself!)</div><div><br></div><div>Notice the right recursion in WellLabeledStatement's rule.</div><div><br></div><div>The idea is to allow</div><div><br></div><div>    javascript:42</div><div><br></div><div>and other such "not-well-labeled statements" for backward compatibility, but only at top level in SourceElement context. Not after a { that starts a Block.</div><div><br></div><div>After a { that starts a Block, you can have a label only if it is followed by a statement that could possibly use that label (labels may nest in such a WellLabeledStatement).</div><div><br></div><div>Any expression after a label that follows a { therefore must be the value part of a PropertyNameAndValueList in an ObjectLiteral.</div><div><br></div><div>This is a mostly-compatible change. Again props to crock for suggesting restrictions to label usage as a spark that kindled this fire.</div><div><br></div><div>If I have this right, then we could add a new production:</div><div><br></div><div>PrimaryExpression:</div><div>    Block</div><div><br></div><div>to allow blocks as expressions. We'd still need the<span class="Apple-style-span" style="font-size: 14px; "> </span><span class="Apple-style-span" style="font-size: 11px; ">[lookahead ∉ {</span><b style="font-size: 11px; ">{</b><span class="Apple-style-span" style="font-size: 11px; ">, </span><b style="font-size: 11px; ">function</b><span class="Apple-style-span" style="font-size: 11px; ">}]</span> restriction in ExpressionStatement.</div><div><br></div><div>Making blocks be expressions allows us to treat them as zero-parameter block-lambdas: ({<i>statements</i>}) instead of the ugly ({|| <i>statements</i>}). The semantics would be the same as with a block-lambda: evaluation of the Block is deferred until it is called, typeof says "function", reformed completion value is implicit return value, etc. See:</div><div><br></div><div><a href="http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival">http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival</a></div><div><br></div><div>(I haven't unified the above with the block lambda revival grammar yet; one step at a time.)</div><div><br></div><div>Grammar nerds, please validate!</div><div><br></div><div>/be</div></body></html>