three small proposals: the bikeshed cometh!

Mike Samuel mikesamuel at
Thu Apr 29 14:50:35 PDT 2010

2010/4/29 Brendan Eich <brendan at>:
> On Apr 29, 2010, at 2:25 PM, Mark S. Miller wrote:
> On Thu, Apr 29, 2010 at 12:08 PM, Mike Samuel <mikesamuel at> 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

More information about the es-discuss mailing list