ES4 work

Graydon Hoare graydon at
Wed Feb 20 23:23:38 PST 2008

Michael O'Brien wrote:
> Graydon,
> 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 mailing list