Exactly where is a RegularExpressionLiteral allowed?

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Mon Mar 23 16:22:37 PDT 2009

Brendan Eich wrote:
> If you make the /= correction, there is no ambiguity.

Indeed there is no ambiguity; I think Allen's point is that the spec
is currently written in a way that is very unhelpful in allowing one to
conclude that.

> 7.1 last paragraph:
> Note that contexts exist in the syntactic grammar where both a division
> and a RegularExpressionLiteral are permitted by the syntactic grammar;

I believe that statement is wrong.
I gave a detailed argument for why it is wrong at
the only reply was by Eric Suen, and the argument in his post was incorrect.

I'll repeat my argument here for convenience:

  A DivisionPunctuator must be preceded by an expression.
  A RegularExpressionLiteral is itself an expression.

(This assumes that the omission of RegularExpressionLiteral from
Literal is a bug.)

  Therefore, for there to exist syntactic contexts in which either
  a DivisionPunctuator or a RegularExpressionLiteral could occur,
  it would have to be possible for an expression to immediately
  follow [*] another expression with no intervening operator.
  The only case in which that can occur is where a semicolon is
  automatically inserted between the two expressions.
  Assume that case: then the second expression cannot begin
  with [*] a token whose first character is '/', because that
  would have been interpreted as a DivisionPunctuator, and so
  no semicolon insertion would have occurred (because semicolon
  insertion only occurs where there would otherwise have been a
  syntax error); contradiction.

  [*] Ignoring comments and whitespace.

> however, since the lexical grammar uses the InputElementDiv goal symbol
> in such cases, the opening slash is not recognised as starting a regular
> expression literal in such a context. As a workaround, one may enclose
> the regular expression literal in parentheses.
> ASI strikes again:
> a = b
> /hi/g.exec(c).map(d);

Semicolon insertion is not possible after 'b', because the '/' following
it is a valid token in that context, so there is no syntax error that
could prompt semicolon insertion.

> The Note takes care of this.

This is not a case where the note applies; it's essentially the same
case as given by Eric Suen. My response to him is at

David-Sarah Hopwood ⚥

More information about the Es-discuss mailing list