graydon at mozilla.com
Wed Feb 20 23:23:38 PST 2008
Michael O'Brien wrote:
> Thanks -- that helps to understand the status.
> You are in a somewhat unique position having implemented more than any
> other. Given Jeff's roadmap outline and the goal of weighing the
> features against implementation experience -- which of the features that
> you have implemented do you feel were difficult, costly or problematic?
Actually, despite my having acquired some sort of "RI maintainer"
moniker, I did not write the majority of it. By volume I think the
largest parts have come from Adobe and Opera people. The builtins and
frontend each weigh about as much as the remainder (machine model,
evaluator, type system).
My sense was that I had the most difficulty with the type and scope
rules, but not so much because they were "problematic" as much as that
we kept changing the rules. Also that even a minor bug in the rules
typically produces a non-booting system, as the builtins stop working.
There was also (and continues to be) considerable subtlety in wiring up
convincing builtin classes that behave "the same" as the ES3 primitives
and ad-hoc host objects.
I can certainly imagine your experience though: if one doesn't have
namespaces or the "proper" block scope forms in the system to start
with, retrofitting them will likely be annoying. Likewise types. But the
RI had some portion of these from the get-go (we retrofitted a unified
scope-initialization primitive into it once the rules became clear half
way in, and this was costly).
Structural types will probably pose a bit of pain because they require a
type-term normalizer with some subtle parts. There is an example in
type.sml but it's certainly not the sort that illuminates the subtle
points! It should be cleaned up during spec'ing. That normalizer also
gets significantly weirder once you introduce type parameters (it turns
into a sort of partial evaluator).
More information about the Es4-discuss