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 <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
