<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 21, 2008, at 2:24 PM, Maciej Stachowiak wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div>On Feb 21, 2008, at 10:41 AM, Brendan Eich wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">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.</span></div></div></div></blockquote></div></blockquote><div><br class="webkit-block-placeholder"></div>Neither does anyone else. That's the point of the co-evolved implementations and specs. Sorry if this is unclear. Michael O'Brien's messages have been painfully clear on where specs are lacking, and before there's an ES4 standard we need to fix those lacks.</div><div><br><blockquote type="cite"><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; "> I am not asking for a finished, formal, final detailed spec.</span></div></div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>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.</div></div></blockquote><div><br class="webkit-block-placeholder"></div>No, we're not turning anyone away for not diving into the deep end of the pool Michael already dove into. We need specs, but they need to be informed by ongoing, well-ordered implementation work. Where we have good-enough specs already (Graydon listed many places near surface syntax), we're ready -- indeed JS1.7 included a bunch of these in order to shake out specs and provide implementation and field-testing feedback. The deeper unresolved issues to do with numbers, e.g., need more spec work, I agree.</div><div><br><blockquote type="cite"><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The proposals on the wiki are <span class="Apple-converted-space"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">way out of date, it's not easy to find what trac tickets modified <span class="Apple-converted-space"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">them, and there seem to be commonly understood planned changes that <span class="Apple-converted-space"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">aren't even reflected in trac.</div></blockquote><div><br class="webkit-block-placeholder"></div>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 <a href="http://bugs.ecmascript.org">http://bugs.ecmascript.org</a>/ soon or they won't happen.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>I have no idea what changes aren't in trac.</div></div></blockquote><div><br class="webkit-block-placeholder"></div>You wrote "there seem to be commonly understood planned changes that aren't even reflected in the trac." I'm asking you what exactly you meant.</div><div><br><blockquote type="cite"><div><div> 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.</div></div></blockquote><div><br class="webkit-block-placeholder"></div>A Mozilla IRC channel and an anonymous respondent -- I don't know what to say. Let's just start fresh here, ok?</div><div><br><blockquote type="cite"><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">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.</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div>The only way to proceed is case by case, but I think we've already identified the RI as an informative artifact, not just in people's heads, but something you are not able to use. That is  a pity, but perhaps we can work around it.</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">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?</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div>No, probably that's the first order of business, and it should not take that much time.</div><div><br><blockquote type="cite"><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">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.</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div>The preference has been to work via the trac to produce sub-specs instead of editing the old (sometimes mis-named) proposals: pages on the wiki. Whatever we do, I agree we need to get rid of the out of date docs. This has been a recurrent problem; sorry for it.</div><div><br><blockquote type="cite"><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">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?</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div>A type annotation is not a "leaf feature" like a new tag in HTML5. It involves foundational issues. The answer at this point involves reading Cormac's paper, and the RI. We can work from here toward a final spec which will entail prose, but it may also use conventional formalisms for type rules, and it will be based on checkable RI code, even if that is not directly excerpted into the spec.</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">In contrast, with CSS, Web API or HTML WG specifications, I can point  </span></div></blockquote><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">engineers to a spec that is more or less accurate for a given feature <span class="Apple-converted-space"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">and they only have to ask questions about the few missing details.</div></blockquote><div><br class="webkit-block-placeholder"></div>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.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>I'm not asking for a spec that won't substantially change.</div></div></blockquote><div><br class="webkit-block-placeholder"></div>That seems to contradict "only have to ask questions about a few missing details", but ok.</div><div><br><blockquote type="cite"><div><div> 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.</div></div></blockquote><div><br class="webkit-block-placeholder"></div>Good to hear.</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">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.</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div>Never said it was imaginary. Why are you again making straw men?</div><div><br class="webkit-block-placeholder"></div><div>I'm pretty blunt about when we have unsolved problems to solve before us. I'm not trying to look good here. My mail and Jeff's were invitations to help solve problems. Seems to me you are demanding solutions before joining in the work.</div><div><br><blockquote type="cite"><div><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; "> I'm not worried about the spec changing out from under us, so much as understanding what the starting point even is.</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div>That is fair, and we should order the proposals before anyone starts implementing who has not yet implemented.</div><div><br><blockquote type="cite"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">In Jeff's timeline, the "feature spec" step comes after "implementation".</span></div></blockquote><div><br class="webkit-block-placeholder"></div>Yes, and I followed up pointing out that the order is not simple waterfall, either implement then spec or vice versa.</div><div><br><blockquote type="cite"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; "> 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 implement?</span></div><div></div></blockquote></div><br><div>Of course you are right -- something other than an existing commercial implementation has to be a starting point. However, the RI is not something to dismiss as quickly as I think you have dismissed it.</div><div><br class="webkit-block-placeholder"></div><div>/be</div></body></html>