Maciej Stachowiak wrote: > To expand a bit on Geoff's comment: > > I'd like Apple and the WebKit project to get involved with ES4 > implementation.
Great! Though please keep in mind a point in the remainder of your comments: WebKit (and Rhino) are operating from a somewhat "newcomer" perspective, relative to the committee. The other 5 implementations in question (RI, spidermonkey, mbedthis, futhark, ESC+tamarin) are all written by engineers who are and have been closely following the tickets, proposals and discussion, and modifying the RI to encode their thoughts / experiment with a feature. So the implication that the language "designers" are a disjoint set from the "implementors", or that they haven't been writing their thoughts down, is not historically accurate. If that's becoming more true now, ok, maybe we need to make some adjustments. But understand where we're coming from. > 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 agree this would be nice, but it'd also be nice to have 9 finished implementations and a finished spec! We don't have these yet. So: is your team *completely* stalled until we have such documents, presumably in english rather than SML? If so, I (or anyone else who understands the issues clearly enough -- they're not tremendously complex) can make a priority of building up foundational "implementors documents" covering such basic concepts as namespaces, names, multinames, types and fixtures. I think we had hoped the RI and tickets on it to serve this role. > 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. > But it seems to me that this undermines the unstated assumption of > interoperable *independent* implementations. I do not think it undermines the assumption of independent implementations, but I also don't think there's a perfectly clear line between "dependent" and "independent". Impls inform themselves from somewhere, be it spec or spec-that-is-informed-from-other-impls or other technical reference material. Information flows somehow, and often between impls (even if indirectly). You're not going to be doing WebKit by studying Futhark or Spidermonkey; but I *would* recommend studying the RI (and contributing to it!) I would not worry greatly about the risk of being "dependent" on it, since it is in a very different language (SML) than WebKit's interpreter and is surely structured quite differently. Study it and understand it, though, as it's as precise as we currently get. The RI was meant to be studied (a.k.a. "reverse engineered") and the risk of overspecificity from that is something we all explicitly agreed was better than the risk of deploying underspecified and incompatible impls to the field. > 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. 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. HTML5 is a laudable example, and I hope we wind up producing something of similar quality. It has also had more energy put into it, more eyes on it, and is a much wider and flatter spec (fewer subtle interlocking issues). Web browsers are also stunningly more complex than programming languages, so the concept of a "reference implementation" is completely fanciful (though you could do a reference implementation of the parsing rules, say). The ES4 RI is small and digestible. Discounting the builtins and some obvious support code, here is the guts of it according to wc -l: 595 ast.sml 134 multiname.sml 923 lexer.sml 7468 parser.sml 2687 defn.sml 1008 verify.sml 5558 eval.sml 913 type.sml 1254 mach.sml 20540 total This is not a big program, it's really small enough to study and participate in. I'd argue that you'd even be in a good place simply reading ast, multiname, eval, type and mach (8.5 kloc). It's intended to be a place for implementors to encode their thoughts and experiments, refer back to, write canonical algorithms in, etc. Don't be shy about using it that way. It's public source. It was intended to be illustrative ("how is this supposed to even work") rather than simply consultative ("what is the magic ES4 oracle answer to this"). (We're probably going to shift it out of monotone and into mercurial soon, which will make it both easier to fetch and more web-accessible too). Is this an unsatisfactory answer? It's possible -- I hope not true -- that the RI strategy will simply not be acceptable to the more recently-arriving implementors (those of WebKit and Rhino). It was acceptable 1.5 years ago when we set out to write this way, but times change. -Graydon _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss