ES4 implementation process, teams, and meetings

Maciej Stachowiak mjs at
Thu Feb 21 14:24:29 PST 2008

On Feb 21, 2008, at 10:41 AM, Brendan Eich wrote:

> On Feb 21, 2008, at 8:30 AM, Maciej Stachowiak wrote:
>> I'd like Apple and the WebKit project to get involved with ES4
>> implementation. But right now, as far as I can tell, there isn't a
>> written record for any of ES4's features that I could point an
>> engineer to and say "implement this".
> There's certainly no such spec, or you would be a passive observer  
> of a standardization process that was all but done. That's not  
> reality, and it arguably is not what you should want -- Apple people  
> could be valued peers in the remaining work on ES4.
> If you want to be passive implementors of a finished spec, then wait  
> till next year.

We'd like to be active participant. However, it seems like as  
newcomers/outsiders, we do not have enough information available to  
participate in early implementation. I am not asking for a finished,  
formal, final detailed spec.

What I am asking is this: for each proposal where you'd like early  
implementations, before implementation commences please write down  
enough information about that proposal in some reasonably  
understandable form to represent the current shared understanding of  
the insiders/old-timers. That would be enough info for us relative  
outsiders/newcomers to participate. I don't think it's too much to ask  
for a rough but up-to-date and accurate first draft. I'm not sure how  
we are supposed participate otherwise. Maybe it is not expected that  
we would or should.

>> The proposals on the wiki are
>> way out of date, it's not easy to find what trac tickets modified
>> them, and there seem to be commonly understood planned changes that
>> aren't even reflected in trac.
> That's a failure to file trac tickets -- could you please list these  
> changes that aren't in the trac? There's no other bug system to  
> track these planned changes, so they had better show up at 
>  soon or they won't happen.

I have no idea what changes aren't in trac. In the past I've asked  
questions on #jslang or elsewhere about particular proposals (such as  
the parametric types proposal) and been told that many things about it  
had been changed, and the person telling me wasn't sure if all these  
changes had trac tickets, or if so, what they were.

It really seems to me like in many cases there is a shared  
understanding among many of the insiders that is only recorded inside  
people's heads. Maybe that's not right, but that is certainly the  
impression I've gotten every time I have asked questions about where  
something is documented.

>> Before attempting interoperable implementations of particular
>> features, I think we need at minimum a form of the proposal for that
>> feature that is complete and up to date. It doesn't have to be formal
>> specification quality, but there has to be something accurate.
> I've worked pretty hard to keep proposals such as iterators and  
> generators up to date; it depends on other proposals which are also  
> not formal spec quality, but stable and meaningful (structural  
> types, type parameters). Cormac has done work recently in  
> formalizing the type system which was important to Graydon's RI work.

Great, if some proposals are accurate and up to date enough to drive  
an initial implementation, then my concern is addressed for those  
features. But I don't know how to tell which ones those are. Is there  
a list of which proposals are up to date?

Furthermore, this won't help when it comes time to implement proposals  
that *aren't* up to date. All I'm asking is that they be brought up to  
date first.

> So I think you are generalizing unfairly here.
> It's true that decimal is out of date in the wiki, and there are  
> open trac issues. This is true of other proposals.
>> Now, it may be that by telling someone to reverse engineer another
>> implementation, or ask the ES4 crowd about every detail of how a
>> feature should be implemented, someone could succeed in implementing.
> Nice strawmen, but no one proposed those things.

Then what is proposed? If I ask an engineer on my team to implement a  
feature such as type annotation, how should I ask them to proceed?

>> But it seems to me that this undermines the unstated assumption of
>> interoperable *independent* implementations.
>> In contrast, with CSS, Web API or HTML WG specifications, I can point
>> engineers to a spec that is more or less accurate for a given feature
>> and they only have to ask questions about the few missing details.
> And then Hixie goes and rewrites it. I am calling b.s. here, Maciej.  
> We implemented offline web app support early in Firefox 3, based on  
> such WHAT-WG (ok, not HTML WG at the time) specs. They changed a  
> great deal later.

I'm not asking for a spec that won't substantially change. The whole  
point of early implementations is to improve the spec, and sometimes  
that may take significant redesign. Safari has been hit by this as  
well, and we accept that as a risk we take on as early implementers.

What I am asking for is a spec that reflects what people are expected  
to implement as a first pass. I seriously don't know how to tell what  
that is. It sounds like there's a possibly out of date proposal, a  
possibly buggy reference implementation in a programming language that  
no one working on Safari/WebKit/JavaScriptCore currently knows, plus  
some trac tickets, plus some insider knowledge. That's not enough for  
those who aren't insiders. And it sounds like Michael O'Brien, who is  
a relative insider compared to me, is having the same problem, so I  
don't think it is imaginary on my part. I'm not worried about the spec  
changing out from under us, so much as understanding what the starting  
point even is.

>> I would raise HTML5 as a particularly laudable example because it
>> achieves this even though much implementation work is happening in
>> parallel with writing the spec.
> You are misrepresenting what has actually happened there.
>> I think we should strive to achieve the same standard for ES4. At
>> feature granularity, someone should first write an up to date  
>> accurate
>> document and implementations should be done against that, not against
>> some separate shared understanding of the feature.
> That's the plan -- see Jeff's paragraph about "feature specs" which  
> I cited in reply to Geoff.

In Jeff's timeline, the "feature spec" step comes after  
"implementation". I am asking that the order be changed. I think the  
first cut of the feature spec should come before implementation, and a  
revision afterwards. Otherwise, how are we supposed to know what to  


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Es4-discuss mailing list