Re: Conflicts between W3C specs and ES5?

On Nov 17, 2009, at 11:03 AM, Maciej Stachowiak wrote:

> On Nov 17, 2009, at 7:32 AM, Brendan Eich wrote:
>
>> On Nov 16, 2009, at 4:28 PM, Maciej Stachowiak wrote:
>>
>>>> The opportunity cost (that you spend time on trailing edge stuff  
>>>> instead of better leading edge work) is very high too.
>>>
>>> Did you look at the contents of the Wiki page? foo.arguments is  
>>> not in there, nor is anything of a similar level of evil.
>>
>> You're right -- I brought foo.arguments up because it is  
>> implemented by V8, and based on stealth-mode development combined  
>> with web testing. So why isn't it on that wiki page? In principle  
>> it should be, since it was required for web compatibility according  
>> to V8 developers' testing.
>
> You'd have to ask the authors of the page that. I assume it's  
> because the page constitutes scratch notes and is not exhaustive.

Yes, and since I opened my big mouth about foo.arguments, James now  
avers that it should be added to that wiki page. So my point stands:  
it looks like incipient over-specification, specifically of  
foo.arguments, RegExp statics, Date.parse, non-standard eval, possibly  
settable __proto__.

No big deal, it's just a wiki. But there's a big-picture issue here,  
to do with trailing edge over-kill vs. alternatives that move the  
leading edge forward. Sometimes the intersection semantics among  
browsers for a given API or syntax and semantics are so broken that  
developers avoid the feature already, and a new-and-better way can be  
promulgated (not designed by committee, but designed in the open and  
trial-implemented).

I do not believe we have infinite and pre-specialized labor available  
(we = all of us reading this, and our colleagues) to both over-specify  
legacy and try to move forward with better specs. Worse, over- 
specifying legacy has inherent costs, not only opportunity costs: it  
can lead to de-jure constraints on future evolution that do not exist,  
or are not very strongly felt by most developers, at any rate, on the  
web. Those de-jure constraints can then beget dependent content.

This is why I'm picking on foo.arguments. It's just a convenient devil  
to whip ;-).


> I'm personally fine with specifying this kind of functionality at  
> the HTML level. But is it appropriate for a spec layered on top of  
> ECMAScript to add methods to String.prototype?

If they're not enumerable *and* they are based on a de-facto standard,  
sure. Object.prototype is a different issue of course. No new de-jure  
augmentation benders. We'll see what Ajax libraries do with ES5's  
Object.defineProperty and standard prototypes. I have heard Prototype  
(the JS library) fans who want standard prototype augmentation, for  
most natural (idiomatic) and concise library style.


>>> Let's save our outrage for features that actually break conceptual  
>>> integrity of the language, rather than just being slightly lame.
>>
>> This is not about "evil" or "outrage", it's about economics. How  
>> much time should we spend on trailing edge stuff that may be so  
>> little used it could be evangelized away?
>
> Is it economically worthwhile evangelizing away the String.prototype  
> functions, relative to the cost of specifying them (since they are  
> already interoperably implemented)?

No, you brought up those String.prototype helpers and I agreed they  
could be spec'ed pretty easily (self-hosted using ES5, even). My bone  
of contention was foo.arguments, remember?


>> Anyway, we didn't slow ES5 down for the stuff on the wiki page, and  
>> I do not think we should have delayed it one day.
>
> As far as I can tell, no one has argued that you should have.

You did, here:
>


http://old.nabble.com/Re%3A-Another-de-facto-insecurity-we-need-to-fix-in-ES5-p24085298.html

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.

Hindsight is wonderful, but even if we fallible TC39'ers had managed  
to use our time better over the last few years, I can think of many  
more important things to do than spec de-facto __proto__ (the topic of  
the thread you replied to). At least with ES5 the needs for __proto__  
apart from the evil case of mutating an existing object's  
[[Prototype]] are well-served by standard APIs like Object.create and  
Object.getPrototypeOf. Spec'ing those instead of __proto__ was a trade- 
off that I can defend.

I have an easier time defending against our not spending time on  
Date.parse legacy (rather than ISO-8601) or the HTML string helpers!


> I think the relevant question is what, if anything, to do with this  
> info in the future.

Fair enough. That whatwg.org wiki page is fine as a grab-bag of worry  
beads, but we should strive to agree on needs spec'ing by TC39 in the  
core language.


>>> You also said (earlier) that the page describes browser  
>>> differences, but from my reading many (most?) of the things  
>>> mentioned are totally cross-browser compatible, just not specified  
>>> anywhere yet.
>>
>> RegExp statics probably do not interoperate fully (we save, clear,  
>> and restore across certain boundaries; other ugly details elude my  
>> memory at the moment).
>
> They seem to interoperate enough that you have to implement them. Do  
> you believe they can and should be evangelized away?

We're going to survey and see what can be done. Help welcome.


>> Date.parse we've discussed. Non-interoperable mess in detail, many  
>> corner cases (IE seems to apply heuristics, not sure whether locale- 
>> specific, to mm/dd vs. dd/mm month-day order, for example).
>
> Indeed, and these notes don't even try to define some sort of  
> interoperable subset. Regrettably we may want to leave this one alone.

Just a statement that there are limits to specification here would  
relieve my tension, let me tell you.


>> Date.UTC. I agree that's a small issue, easy to spec -- a bug on  
>> ES5 if you will. Too bad it wasn't reported (AFAIK).
>
> Maybe it can get picked up in the next version.

Sure. Best to file a trac ticket at http://bugs.ecmascript.org/ --  
note to self or anyone else reading with access (if you lack access  
and want it, mail me).


>> 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?


>> Evil eval (outside of what ES5 specs; and yes, I'm moralizing now,  
>> you'll know it when I do :-P) is a non-interoperable zoo, see  
>> Pratap Lakshman's "JScript Deviations from ES3" doc:
>>
>> http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%3Aresources&cache=cache&media=resources:jscriptdeviationsfromes3.pdf
>
> It does seem that sites depend on the intersection semantics. Is  
> this one to evangelize again?

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).


>> HTML comments is a worthwhile spec for someone to construct but  
>> again, it seems better left ouf of the core language spec, since it  
>> is embedding-domain-specific. Sure, an important embedding, the  
>> most important -- but it is separable (ignoring E4X) and probably  
>> better dealt with in w3c/whatwg.org as a practical matter.
>
> 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, or in an external script, or (as far as  
> I know) passed to eval()

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.


>> Property Enumeration is an ongoing issue in Ecma TC39. I believe  
>> you did some useful testing and posted results to es-discuss.  
>> Anyway, I'm not picking on everything in the wiki page, and  
>> probably Mark was not either. He was on the look-out for stuff to  
>> spec in Ecma, and probably for stuff we want to deprecate, at a  
>> guess. I'm with him on that last point.
>
> I think he was concerned that there were other unflagged direct  
> conflicts between HTML5 (or other W3C specs) and ES5, hopefully we  
> have laid that to rest.

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.


>> IIRC, you objected after the fact that ES5 (3.1 at the time) didn't  
>> standardize my fine old hacks (these all came from Mozilla about  
>> ten years ago).
>
> If it was still 3.1 at the time, then that was hardly after the  
> fact. But I'm not actually sure what you're referring to.

See your mail from July cited above.


> I think I generally advocated for specifying de facto behavior and  
> in particular for not having the spec require things contrary to de  
> facto behavior, but I don't believe I made a bright line principle.

True. The difference in emphasis may be slight, but it could cause  
major rear-looking standardization. Anyway, as I wrote to Anne --  
anyone crossing my bright line of death must do the work (good luck  
with Date.parse) and then persuade me to spend scarce time reviewing  
it. I'm not an outlier in resisting such quixotic efforts.


>> I think you were too late, and although I agree in general de-facto  
>> beats a de-jure "cleanup" that incompatibly innovates, I'd say  
>> ES5's APIs are "better enough" that the design-by-(sub-)committee  
>> exercise led by Allen Wirfs-Brock worked, this time. But this is  
>> not a clean situation and I don't (and didn't) moralize about it.
>>
>> The argument I was having, which you kindly interrupted (no  
>> problem! ;-), was against indefinite and blind over-specification.  
>> The wiki page is a mix, as you say. But only some of it fits in  
>> ECMA-262. Where does the rest, if we agree to cut the crazy over- 
>> specification, belong?
>
> I think the argument you were having was against a position that no  
> one has taken.

I don't think so. Clearly no one wants to endorse "blind over- 
spefication" but I've heard either "let's specify legacy crap feature  
X fully, it's easy" when it's neither easy nor necessary to over- 
specify. I've also heard "we will specify all effects other than those  
dominated by hardware issues". Evidence:

http://lists.w3.org/Archives/Public/public-html/2009Oct/0365.html  
(Anne on document.all)
http://lists.w3.org/Archives/Public/public-html/2009Oct/0368.html (my  
reply to Anne)
http://lists.w3.org/Archives/Public/public-html/2009Oct/0396.html  
(Hixie, same thread)

Hixie and I exchanged a few more messages on that "typeof  
document.all" thread, but I don't think we came to much of an  
understanding. I owe him some data on cross-browser interop-hazard  
results to do with memory management. But the general issue of  
specifying too much legacy is still unresolved, AFAICT.

/be