On Feb 21, 2008, at 10:31 AM, Graydon Hoare wrote:
> 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.
I don't think the sets are disjoint, but they are not identical either.
>> 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.
I don't think foundational documents are what we need to implement
specific features. What we need are rough cut but accurate specs for
the features to implement. I don't think SML + trac is a form that
anyone here can easily understand.
>> 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.
Well, neither I nor anyone on my team know SML. Nor do we know the
internals of the reference implementation, what aspects of it are
normative, which are implementation details, and which are considered
bugs and are intended to change. Nor would I know where in the RI to
look to understand how to implement particular features. For example,
"let" binding was raised as an example of a possible early
implementation feature. I don't know where in the ~40 klocs of SML in
the repository I should look.
>> 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.
For reasons stated, the RI is not really sufficient for those of us
who haven't been in the guts of the RI all along (perhaps not even for
some that have been). I don't think it's asking too much to request up-
to-date prose descriptions of features to be implemented, possibly
with cross-references to the RI and/or trac to cover particular
details. If learning SML is really a prerequisite to being one of the
early implementors, then I am not sure anyone working on WebKit/
JavaScriptCore is qualified, which is a pity. If learning SML is a
prerequisite to understanding the finished spec, then that will be a
pretty high barrier to entry for even non-early implementors.
I tried reading over some of the SML files you mentioned and without
context or knowledge of the language I could not make heads or tails
of them. The first function I read was extractRuntimeTypeRibs and I
can't tell what it's doing or how (or what aspects of the ES4 language
it relates to).
Regards,
Maciej
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
