On Jun 28, 2011, at 4:35 PM, Breton Slivka wrote: > 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?
There's no point redoing the built-in statements that way, and we cannot handle the "else" keyword or "while" in do-while loops without yet more magic. I don't think it's worth it, yet. > 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. No worries. And note that I did not unify block with object literal so much as disambiguate them. But I think there's an LR(1) ambiguity (fixable) still. More in a bit. /be > -Breton Slivka > > > On Wednesday, June 29, 2011, Brendan Eich <bren...@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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss