Re: Conflicts between W3C specs and ES5?

On Nov 17, 2009, at 5:41 PM, Brendan Eich wrote:

> On Nov 17, 2009, at 3:25 PM, Maciej Stachowiak wrote:
>
>
>
>>> Ok, it was last July, and you allowed how it was too late then for  
>>> ES5, but the implication was that we ought to have spec'ed such  
>>> things already. And I might agree, if only there weren't more  
>>> pressing priorities, and the problem of scarcity causing us to  
>>> defer a great many work items to after ES5.
>>
>> My message was pretty clearly about what to do in the future, not  
>> recriminations about the past.
>
> I don't think I'm misreading your message. Recrimination is not the  
> issue. The issue is de-facto standard codification, however  
> distasteful, vs. a cleaner standard that could supersede the de- 
> facto standard. You framed this pretty well with __proto__ as the  
> concrete case.

I wouldn't even frame it as a versus. I am not against having legacy  
features marked as deprecated *and* providing a cleaner way to do the  
same thing, when that makes sense. Or specifying legacy features as  
optional. Or mandating non-implementation of certain legacy features.  
What I don't like is the specs acting like legacy features don't exist.

My message included both specific comments about __proto__ (where I  
said I don't like the writability and wish it would die) and a general  
statement on legacy features. This was not intended to imply that  
__proto__ is the best test case, since at the very least writable  
__proto__ is something we'd prefer to phase out if that is possible.

>
>>>>> Global scope vs. global |this| is indeed a conflict as Mark said  
>>>>> in his original post.
>>>>
>>>> Yep. Hopefully we can find a clever way out of this in the future.
>>>
>>> We could just underspecify the core language but that is  
>>> suboptimal, to put it mildly. The other extreme is to bring Global  
>>> and GlobalProxy types or similar abstraction into ECMA-262. Is  
>>> there a middle way?
>>
>> I discussed this briefly over lunch with some TC-39 folks during  
>> the W3C / TC39 face-to-face recently. One idea was to remove the  
>> notion of global object as a reified object from ECMAScript  
>> entirely - then it can be specified completely at the Web standards  
>> level in terms of relations
>
> See http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope  
> for a proposal that does remove the formerly-global object as a  
> scope chain element.
>
>
>> It's not clear to me whether this is really doable.
>
> What would |this| bind to in global code? We could make it denote  
> the undefined value but only under some opt-in stricter-than-strict  
> mode. Doing so would be hostile to code migration, though. The  
> lexical_scope proposal leaves |this| in global code bound to the  
> "global object".

I'll have to study and think about this to decide if it's enough,  
without providing some way for particular embeddings to change what  
"this" points to in global code. Thanks for the pointer!

>
>
>>> Indirect eval is global eval in ES5. But which global? This is a  
>>> weakness in ES1-5. The interpretation that I favor, which Mozilla  
>>> at least implements, uses the global in which the indirect eval  
>>> function was defined (eval is a global function).
>>
>> Our behavior (as far as I can tell):
>>
>> otherWindow.eval("...") evaluates with otherWindow as the global  
>> object.
>> randomObject.eval("...") throws
>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws
>>
>> In other words, eval's this value must be the same as the global  
>> object that defined it, else we throw.
>
> What is the rationale for throwing in this last case, rather than  
> using the explicit base object (otherWindow) as |this|?

I'm not necessarily advocating this particular behavior, just  
describing it (based on code inspection). I would guess one reason to  
throw is to avoid answering whether the |this| value should be  
otherWindow, or the window in which copyOfEvalFromYetAnotherWindow was  
originally defined. I have no problem with either of those  
alternatives, personally.

>
>
>>>> So you think it's appropriate for a W3C spec to add to the  
>>>> lexical syntax? I think it's been previously assumed this would  
>>>> be a bad idea. Note that it's not completely HTML-specific  
>>>> because JavaScript in an SVG <script> element,
>
> I forgot to ask: doesn't JavaScript in SVG require a CDATA marked  
> section around the inline <script> content, which the XML processor  
> handles? The JS engine never sees that marked section.

It does not necessarily require a CDATA section; depends on whether  
you want to use characters in your JS that are reserved in XML. But  
the text contents of the CDATA are passed to the JS engine verbatim,  
and may include HTML-style single-line comments.

>
>>>> or in an external script, or (as far as I know) passed to eval()
>
> I hope it won't shock you to learn that
>
> <!--
>
> and
>
> -->
>
> have been observed in the middle of external .js files loaded by  
> <script src="foo.js"></script> :-(. Refactoring contagion vector.
>
> So yeah, messy. Nevertheless, ECMA-262 implementations in embedded  
> devices with no web contacts may not care to hassle with the horrors  
> of these old comment-hiding hacks. Informative Annex? Optional-but- 
> normative-if-implemented section?

My personal inclination would be to make it fully normative unless  
someone actually complains about the effort of implementing it in  
their embedded context, relative to the benefit of better aligning  
with JS as she are spoke on the Web.


>
>
>>> True, this is a messy issue. Browser JS implementations treat -->  
>>> differently, as the wiki notes. Possibly this has to go in the  
>>> core, although again it seems fruitless to require for siloed  
>>> embeddings that have no commerce with web JS.
>>
>> My personal tentative sense is that having a consistent lexical  
>> grammar (and having that fully specified in the core spec)  
>> outweighs the savings of effort for non-Web-hosted implementations.  
>> "<!--" itself seems to have consistent behavior. For "-->" there  
>> are differences and quirks. I think the SpiderMonkey behavior for  
>> "-->" seems fine and not overly complex. Really this is not much  
>> more complicated than "//" comments.
>
> Ok, then we need someone to contribute a spec -- we can link a  
> placeholder here:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:strawman

Cool, thanks for guidance on the process. Perhaps the authors of the  
Wiki page will be encouraged to contribute.

>
>
>>> Mark, please speak up. I believe TC39 members including Mark and  
>>> me are concerned about both unflagged conflicts *and* over- 
>>> specification of legacy stuff we don't think should be formalized  
>>> if it can be deprecated effectively.
>>
>> This wiki is all about stuff that's widely implemented, and not  
>> about the contents of specs as such. So it's not a very helpful  
>> guide to finding instances of
>
> Lost text -- please continue.

Sorry about that!

>> This wiki is all about stuff that's widely implemented, and not  
>> about the contents of specs as such. So it's not a very helpful  
>> guide to finding instances of

...spec-level conflicts with ES5.

In other words, most of this stuff is in no spec whatsoever, except as  
noted (afaik).

>
>
>> What is your bright line?
>
> Don't spec de-facto Date.parse.

OK, I thought you meant something more general than Date.parse. Thanks  
for clarifying.

Cheers,
Maciej