2010/4/29 Brendan Eich <[email protected]>:
> On Apr 29, 2010, at 2:25 PM, Mark S. Miller wrote:
>
> On Thu, Apr 29, 2010 at 12:08 PM, Mike Samuel <[email protected]> wrote:
>>
>> Yeah, I'm on the other side. I think that all new productions that
>> introduce a new keyword should be restricted. We have enough
>> semicolon insertion problems already!
>> :)
>>
>
> +1. I think all new productions should be restricted whenever the lack of
> restriction creates either an actual semi-insertion problem, or a visual
> confusion about whether there may be such a problem.
>
> Really, methinks you guys protest too much. In particular Mike's "all new
Methinks "you protest too much, methinks" does not mean what you think
it means :)
> productions that introduce a new keyword should be restricted" is simply
> wrong for "let".
> It is not as if we should have made "if", "else", "for", "switch", etc.
> require the next token ('(' for "if", who knows what for "else") to be on
> the same line. There is no ASI hazard with any of these control-structure
> introducing keywords.
For tokens after which no semicolon can be inserted regardless of next
token, I agree.
For others, I would prefer to limit the spread of semicolon-insertion infection.
And I would note that not restricting productions can make it harder
to introduce new similar grammatical constructs later.
> We're really talking about only postfix ++/--, "throw E", "return E", "break
> L", and "continue L" if memory serves.
And why is "throw" in that category if you're only interested in ASI hazards.
> The other Harmony keyword in mind beyond "let", already reserved in ES5
> strict, and one which might indeed require a restricted production, is
> "yield". If "yield" is supported as in JS1.7+ (after Python 2.5+), you can
> write code like this:
> js> function g() {yield; yield}
> js> for (let i in g()) print(i)
> undefined
> undefined
> You do not have to write "yield undefined;". It's an edge case but a win
> when you need it, and it makes yield like return when used in a statement
> context (we share the recursive descent parsing code in SpiderMonkey).
>
> Whether the infix "!" is used for binding or for asynchronous message
> sending, it needs to be a restricted production so that
> <left-operand>
> ! <stuff>
> is not confused with
> <expression-statement>;
> ! <unary-operand>
> Specifically, infix "!" needs to prohibit a newline to its left.
>
> Indeed, although there's no strawman proposal for "!" yet.
> To quote dherman: syntax, yay.
> /be
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
