July 25, 2012 - TC39 Meeting Notes

David Bruant bruant.d at gmail.com
Tue Jul 31 17:05:08 PDT 2012

I think my message has been taken the wrong way, so I should clarify it:
 From a practical point of view, if 2 implementations differ on one 
aspect of the language, it means that there is no content relying on 
either of the 2 implementations for that aspect of the language, whether 
they follow the spec or even both diverge differently from it.
Not having content relying on this aspect also opens the door to 
changing the behavior if it's considered as a mistake. This applies to 
the "override mistake", but every single test262 test failure on any 
major implementation could also be seen as an instance of such an open 
door to change the spec.
"what the spec says doesn't really matter" seems very negative taken out 
of context, but within the context i said it, it meant something 
positive along the lines of "there is room to improve the specification 
on this part if necessary"
That really is all what I meant, no more, no less.

Also... hmm... I wouldn't be spending that much time on standards 
mailing-list, this one included, if I didn't believe in standardization ;-)

Detailed answer below.

Le 31/07/2012 14:07, Allen Wirfs-Brock a écrit :
> The following was WRT [[Put]]/[[CanPut]] semantic issues:
> On Jul 28, 2012, at 6:02 AM, David Bruant wrote:
>> Le 28/07/2012 14:37, Herby Vojčík a écrit :
>>> ...
>>> :-/ But that is how it is, no?
>> That's what the spec says, but V8 has implemented something else (and I
>> haven't seen an intention to change this behavior), so what the spec
>> says doesn't really matter.
>> David
> I have to disagree with David's sentiments here. Situations like this is exactly why we have standardized specifications.
I agree.
But I'd like to add that situations like this also show the limitations 
of standardized specifications (more on that at the end)

> Different implementors can easily have differing interpretations about the edge case semantics of loosely described features. An important role of standards is to align implementations on a common semantics. Sure, an implementation can refuse to go along with the specification but that is quite rare, at least for ECMAScript where all major implementations seem to recognize the importance of interoperability.
I do the opposite analysis: major implementations recognize the 
importance of interoperability due to market constraints, thus the need 
for a standard.
Although almost no one talks about it these days, I think the most 
important part of HTML5 was specifying what's already in some browsers, 
making clear for the other browsers what to implement to be interoperable.

> In particular, I haven't seen any indication that V8, as a matter of policy, is refusing to ever correct this deviations.
> It's true that what the spec. says makes no difference to the browser bits that have already been shipped.  It does make a difference over the long term.  Single implementation deviations from the specification usually get fixed eventually. Conformance to the specs. is a motivator for implementors.
> We really shouldn't foster the meme that  specs don't really matter.  they matter a lot.
I hope I have clarified that I don't buy into the meme that specs don't 
matter. I was only reacting to the fact the 2 major implementations 
differ on one aspect of the spec, making in practice what the spec says 
on that aspect useless.

Brendan Eich wrote:
> I missed this until Allen's reply called it out. It is both false 
> (Google people at the TC39 meeting last week said it's a V8 bug that 
> is going to be fixed)
it's unfortunate this information wasn't on the meeting notes, but I'm 
glad to hear it :-)

> and a stinky statement of anti-realpolitik. In the current market, if 
> we don't hew to a consensus standard, anything goes.
> Not that everyone would make breaking changes, or any changes, just 
> that from the presence of a bug or long-standing deviation (in this 
> case copied from JavaScriptCore, which has since fixed the deviation!) 
> does *not* mean that "what the spec says doesn't really matter."
I guess I should have added "here" at the end of my sentence to clarify 
that I didn't mean that the whole spec doesn't matter, but only the part 
about [[CanPut]]/[[Put]] that's not interoperably implemented.

> Or were you snarking at V8?
I was not.

More on the limitations of standardization I talked about above.
As I said, I understand the importance of a standard and I don't buy in 
the idea they are useless. I also don't buy in the idea that standards 
should be seen written-in-stone documents. We all know that specs 
sometimes have mistakes in them and when it's necessary and possible, 
they are fixed. It was discovered that ES5 had such a mistake [1] and 
the standard has been consequently fixed. This change additionally to 
implementations following make that what was said in the spec about 
Object.prototype.toString before the fix did not matter (only the part 
that was controversial). The fact that it did not matter was actually a 
pre-requisite to being able to change it, because if it did matter, if 
content relied on that part, the specification couldn't have been changed.

Also, I think there is something much more important than the 
specification document itself which is the standardization process. 
What's happening here (es-discuss and TC39 meetings) is more important 
than writing a document. What's happening is that major stakeholders 
come to an agreement. This is far more important than the standard 
itself. The standard is just the codification of this agreement. For 
things that have been implemented, it's just a reminder. And for 
anything that hasn't been implemented yet, it's just an hopeful promise.
If it happened that some feature made it to an ECMAScript 6 standard, 
but not in any implementation, would it matter? If implementations 
diverge, the standard will have to be fixed anyway, making the previous 
version not-so-standard.
Actually that's a good question: is it planned to have in 
ES.next-the-standard features that wouldn't be implemented at the time 
the standard is released?

I often read on Twitter or blogposts people saying things like "TC39, 
hurry up!" or complaining that the next version of the standard takes 
too much time to be released. I think it's misguided. When the standard 
as a document is released doesn't matter. When implementations are ready 
is. And as we have seen with WeakMaps, it doesn't take a standard, it 
takes an implementor agreement.

I hope I have made my position more clear.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120731/90ccab11/attachment.html>

More information about the es-discuss mailing list