Fun impossible Firefox JS challenge

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Apr 12 09:13:47 PDT 2012


On Apr 12, 2012, at 8:06 AM, Andreas Rossberg wrote:

> On 12 April 2012 16:27, Peter van der Zee <ecma at qfox.nl> wrote:
>> On Thu, Apr 12, 2012 at 4:12 PM, Andreas Rossberg <rossberg at google.com> wrote:
>>>> Haha nice try even with unicode escapes it still refers to "true" the
>>>> boolean not the function.
>>> 
>>> That's another FF deviation from the standard, though.
>> 
>> Identifiers with unicode escapes have the meaning of their canonical
>> value. So wouldn't that (tru\u0065 referring to the bool) be valid and
>> according to the spec?
> 
> Yes, but keywords (and other verbatim tokens, like 'true') are
> recognized _before_ canonicalization. At least that is the intention
> of the spec, Waldemar told me. (I filed
> https://bugs.ecmascript.org/show_bug.cgi?id=277 a few weeks ago as a
> request for making the wording clearer.)

A couple points:

Floating around this area (in Mathias' blog post and Andreas' bug report, etc)) there are references to http://wiki.whatwg.org/wiki/Web_ECMAScript#Identifiers .  It should be used justify any particular interpretation of the ES specification. There is nothing normative about that document and the section on Identifiers is actually labelled as "this is very rough".  Nobody should be making implementation decisions on the basis of that document.

There may well be web compatibility requirements that are not covered by the current ES5.1 spec. We should try to understand those requirements before implementations start trying to match each others deviations from the spec. Difference between implementations suggest areas where there currently isn't complete interoperability in this area so we shouldn't be creating interoperability among spec. deviations (and future compatibility requirements) unless we actually decide we want those deviations to be part of the standard language.

Waldemar's observation may well be correct for ES<=3. He would know, and if that was the intent then I can see how the spec. could be read in that manner.  But for ES5 we rewrote that portion of the specification and introduced the concept of IdentifierName as a lexical category that includes both ReservedWord and Identifier  and all the escape and canonicalization language was applied to IdentifierName rather than Identifier.  This was all intentional.  We certainly didn't expect true and tru\u0065 to be recognized as different identifier names in newly allowed contexts such as:

    obj.true == obj.tru\u0065

I'm pretty sure that no reviewers  brought up issues related to a ES3 interpretation of  unicode escapes as keyword escapes.

At this point I think we need to do two things:

1) Understand the actual browser interop situation. For example, do all major browsers accept:
      var tru\u0065;
2) Within the constraints of 1) decide what we actually want to specify.  Do we want
      console.log(fals\u0065)
to print "false" or "undefined"?
3)  For ES6 we have to decide how \{0065} fits in.

Allen

    




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120412/2a84a821/attachment-0001.html>


More information about the es-discuss mailing list