Exactly where is a RegularExpressionLiteral allowed?
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
> 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
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