On Mar 23, 2009, at 11:36 AM, Allen Wirfs-Brock wrote:
Pratap came up with an issue in reviewing the ES3.1 draft that I
don’t have a good answer to:
Sections 7 and 5.1.2 mention InputElementDiv and InputElementRegExp.
7 "There are two goal symbols for the lexical grammar. The
InputElementDiv symbol is used in those syntactic grammar contexts
where a division (/) or division-assignment (/=) operator is
permitted. The InputElementRegExp symbol is used in other syntactic
grammar contexts."
Where in the grammar (or elsewhere) does it define **when** these
two contexts are used?
There are no subsequent references to InputElementDiv or
InputElementRegExp in either the grammars or the prose of the
specification. Nor, is there any reference to
RegularExpressionLiteral in the syntactic grammar or supporting prose.
So how am I as a language implementer reading this specification
supposed to know that:
var rx = /a*z/;
is a valid expression whose RHS is an RegualrExpressionLiteral? The
best explanation I can come up with for this interpretation solely
from the specification is that the production to the right of the
“=” in VariableDeclaration is an AssignmentExpression that can
reduce to ConditionalExpression and since ConditionExpression
doesn’t describe any non-parenthesized expressions that begin with
“/” or “=/”
=/ is not an operator (it was in archaic, pre-ISO, last-days-of-Disco
C, but long ago fixed to be /=).
I should use InputElementRegExp and accept a
RegularExpressionLiteral as a PrimaryExpression. (and there really
isn’t anything in the specification that tells me to make that last
leap. Actually, I don’t really think that the specification
actually says that the above example is valid.)
If you make the /= correction, there is no ambiguity. 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; 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);
The Note takes care of this.
This isn’t a new ES3.1 problem. Nothing has changed from the ES3
specification in this regard. Am I missing something obvious?
Obviously this can’t be unambiguously specified in the grammar but
it sure seems like there should be some sort of comprehensible
specification of exactly when RegularExpressionLiteral is allowed.
I think that's 7.1.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
