this vs thi\u0073

Lasse Reichstein reichsteinatwork at gmail.com
Wed Jun 22 22:14:51 PDT 2011


On Tue, Jun 21, 2011 at 7:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> ES5.1:
> 7.6.1   Reserved Words****
>
> A reserved word is an *IdentifierName* that cannot be used as an *
> Identifier*.
>

Descriptive.

> ****
>  7.6    Identifier Names and Identifiers****
>
> Identifier Names are tokens that are interpreted according to the grammar
> given in the “Identifiers” section of chapter 5 of the Unicode standard,
> with some small modifications. An *Identifier* is an *IdentifierName* that
> is not a *ReservedWord* (see 7.6.1).
>
...

> Unicode escape sequences are also permitted in an *IdentifierName*, where
> they contribute a single character to the *IdentifierName*, as computed by
> the CV of the *UnicodeEscapeSequence* (see 7.8.4). The *\* preceding the *
> UnicodeEscapeSequence* does not contribute a character to the *
> IdentifierName*. A *UnicodeEscapeSequence* cannot be used to put a
> character into an *IdentifierName *that would otherwise be illegal. In
> other words, if a *\ **UnicodeEscapeSequence* sequence were replaced by
> its *UnicodeEscapeSequence*'s CV, the result must still be a valid *IdentifierName
> *that has the exact same sequence of characters as the original *
> IdentifierName*.
>

No problem here, as  i\u0066  is definitely an IdentifierName (so is "if").



> ES3 didn't distinguish *IdentifierName* from *Identifier* but from a quick
> scan of the ES3 language I don't see that the spec. is any different in this
> regard.
>

Except that there was not syntactic category containing i\u0066 in ES3, but
there is in ES5 (IdentifierName).


> Also, given the pervasive  substitution of Unicode escape sequences I don't
> see why they shouldn't be legal in reserved words.
>

I used to think so too, mainly based on reading ES3, but after reading this
thread a few times, I can now argue either way.

Identifier ::= IdentifierName but not ReservedWord

Since i\u0066 *is* an IdentifierName (it's valid to write  o.i\u0066  and
 {i\u0066: 42}), and it's not a ReservedWord (there are no escapes in the
ReservedWord definition), it must be an Identifier.

In ES3, the resulting character sequence had to be a valid Identifier. That
meant that i\u0066 would not qualify, because "if" was not a valid
identifier. In ES5, as quoted above, it just has to be a valid
IdentifierName, which "if" is


On the other hand, every other use of IdentifierName refers to its
interpreted value, after escape replacement, so that would mean that i\u0066
is not an Identifier, because its value as an IdentifierName is "if", which
is a ReservedWord. That also means that there is no syntactic category for
i\u0066 except IdentifierName. It's neither an Identifier, nor a keyword
(because escapes are not allowed in keywords).

So, it all boils still down to whether the "but not" check is performed
before or after interpretation of the input character sequence, i.e., before
or after replacing escape sequences.
/L


>
> Allen
>
>
>
>
> On Jun 21, 2011, at 5:58 PM, Mike Samuel wrote:
>
> 2011/6/20 Luke Hoban <lukeh at microsoft.com>:
>
> My read of the spec is that thi\u0073 is a ReservedWord and should not be
> allowed as an Identifer.  So the following part of the examples quoted below
> should be an early error:
>
>
>  var thi\u0073 = 42;
>
>
> The text in 7.6 seems to address this with:
>
>
> "All interpretations of identifiers within this specification are based
> upon their actual characters regardless of whether or not an escape sequence
> was used to contribute any particular characters."
>
>
> I don't think this means what you think it means.
>
> I think this means that the identifier foo is the same identifier as
> f\u006fo.
>
> But in
>
> if (false)
> alert(1)
>
> "if" is not an identifier, whereas in
>
> \u0069f(false)
> alert(1)
>
> \u0069f is an identifier which would be the same as the identifier
> "if" if "if" could appear as an identifier unescaped.
>
> Since "this" is not an identifier but appears explicitly in the text,
> that led me to assume that "thi\u0073" should behave differently from
> "this".
>
> Every browser I have tested treats the identifier "i\u0066" distinctly
> from the keyword "if".
> Every browser I have tested treats the identifier "thi\u0073"
> distinctly from the keyword "this" in at least some cases, but only FF
> passes all the tests I've come up with.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110623/af47fbd6/attachment-0001.html>


More information about the es-discuss mailing list