Fun impossible Firefox JS challenge

Allen Wirfs-Brock allen at
Fri Apr 13 09:17:19 PDT 2012

On Apr 13, 2012, at 8:19 AM, Andreas Rossberg wrote:

> On 13 April 2012 16:47, Brendan Eich <brendan at> wrote:
>> Some time after Firefox 4, a fix went in so we match ES5:
>> js> fals\u0065
>> false
>> js>
> Hm, I still don't quite see where ES5 would specify this behaviour.
> The relevant bits I can find are:
> - In 5.1.6: "Terminal symbols of the lexical, RegExp, and numeric
> string grammars, and some of the terminal symbols of
> the other grammars, are shown in `fixed width` font, both in the
> productions of the grammars and throughout this specification whenever
> the text directly refers to such a terminal symbol. These are to
> appear in a program exactly as written."
> - In 7.8.2, the 'false' literal is defined in the aforementioned fixed
> width font.
> - In 7.6, the grammar of identifiers is given to allow unicode
> escapes, but excludes ReservedWords, which in turn include the
> aforementioned literals (in their verbatim form!).

7.6 also provides the grammar for IdentifierName and allows for unicode escapes to appear within them.

> - Also in 7.6, the spec says: "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."
> - Going on, the spec says "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."

The history for the insertion of that sentence is given in 
The use of "Identifier" (rather than "IdentifierName" was in the feedback that seeded the change).  It looks to me like the editor should have replaced "Identifier" with 'IdentifierName" when he added that sentence. There was certainly no intent that {false: 0} and {fals\u0065: 0} would produce objects whose sole own properties had different keys.

> From the first 3 points I conclude that `fals\u0065` is not the
> 'false' literal. It would be an identifier if it wasn't for the 4th
> point. Consequently, the token `fals\u0065` is neither a literal nor
> an identifier!
> The last point merely seems to be talking about "interpretation" of
> tokens that have already been syntactically classified as identifiers.
> I.e. it does not turn `fals\u0065` into a literal again, it only
> results in `f\u0065` denoting the same identifier as `\u0066e`.
> In any case, this should really be clarified.

I agree.

The bigger point is that we have some divergence among implementations.  That gives us space to decide what we really want and then clarify it.

I'ved proposed that we don't want fals\u0065 to be treated as an Identifier.  It is still a ReservedWord even though it is written using a unicode escape.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list