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
