ES4 implementation process, teams, and meetings

Graydon Hoare graydon at
Thu Feb 21 10:31:48 PST 2008

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 

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 


More information about the Es4-discuss mailing list