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

Breton Slivka zen at zenpsycho.com
Tue Jun 28 16:35:12 PDT 2011

Ooo that's exciting! And so, if I'm not being too presumptuous, Does
this mean that constructions like if, while, etc become prefix
operators that can invoke a block lambda?
I've been flat out and haven't been able to look at this so it''s
exciting to see some progress on it. Just in case:
I hereby relinquish all copyright, trademark and patent rights I may
possibly hold, to the idea of "unifying the object literal and block
grammar constructions" to the TC39 group and its constituent members,
so help me god.
-Breton Slivka

On Wednesday, June 29, 2011, Brendan Eich <brendan at mozilla.com> wrote:
> On Jun 23, 2011, at 3:27 PM, Brendan Eich wrote:
> Also, if any { block } could be a lambda, perhaps we won't need that (nor any new) syntax for block-lambdas.
> We would need new syntax still, for formal parameters.
> Making blocks be expressions requires unifying the ObjectLiteral and Block 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 Statement : Block in the current grammar.
> Apologies for not crediting Breton Slivka, who suggested working this approach here:
> https://mail.mozilla.org/pipermail/es-discuss/2011-June/014933.html
> Here's an attempt to formalize the unification grammatically.
> Block:    { UnlabeledStatementFirstList }    { WellLabeledStatement StatementList? }
> UnlabeledStatementFirstList:    UnlabeledStatement    UnlabeledStatementFirstList Statement
> Statement:    UnlabeledStatement    LabeledStatement
> UnlabeledStatement:    Block    VariableStatement    EmptyStatement    ExpressionStatement    ContinueStatement    ReturnStatement    LabelUsingStatement    DebuggerStatement
> LabelUsingStatement:    IfStatement    IterationStatement    BreakStatement    WithStatement    SwitchStatement    ThrowStatement    TryStatement
> LabeledStatement:    Identifier : Statement
> WellLabeledStatement:    Identifier : LabelUsingStatement    Identifier : WellLabeledStatement
> (I'm using the American spelling of "labeled" and "unlabeled". Can't help myself!)
> Notice the right recursion in WellLabeledStatement's rule.
> The idea is to allow
>     javascript:42
> 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.
> 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).
> Any expression after a label that follows a { therefore must be the value part of a PropertyNameAndValueList in an ObjectLiteral.
> This is a mostly-compatible change. Again props to crock for suggesting restrictions to label usage as a spark that kindled this fire.
> If I have this right, then we could add a new production:
> PrimaryExpression:    Block
> to allow blocks as expressions. We'd still need the [lookahead ∉ {{, function}] restriction in ExpressionStatement.
> Making blocks be expressions allows us to treat them as zero-parameter block-lambdas: ({statements}) instead of the ugly ({|| statements}). 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:
> http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
> (I haven't unified the above with the block lambda revival grammar yet; one step at a time.)
> Grammar nerds, please validate!
> /be

More information about the es-discuss mailing list