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
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
