ES4 implementation process, teams, and meetings

Graydon Hoare graydon at mozilla.com
Thu Feb 21 11:28:21 PST 2008


Michael O'Brien wrote:

> As a solution: I think we need an intermediate step. Not a spec, but 
> some detailed design notes. Lar's document was a good
> overview, but drill down on exactly how the mechanisms are meant to work 
> would be very helpful to broaden the base of
> implementations. Some examples of the things I'd like to see are:
> 
>     * Exactly how the scope rules work for various constructs
>     * Order of initialization
>     * More detail on namespace lookup rules
>     * More detail on unqualified variable lookup
>     * Type matching rules and conversions
>     * More detail on nullability
> 
> But there is a lot more. We can do this via Q&A, which is what we have 
> been doing, but it is hard and requires quite a bit of sleuthing.

I see. I would have hoped these would be visible more or less directly 
by inspection:

   * the scope rules and initialization order of each construct are
     elaborated production-by-production in eval.sml

   * the namespace lookup scheme is elaborated in multiname.sml,
     fixture.sml and defn.sml

   * the unqualified lookup rule starts in eval.sml
     (evalLexicalRef -> evalRefExpr -> resolveOnScopeChain ->
     Multiname.resolve)

   * the type matching and conversion rules begin with runtime judgments
     in eval.sml (evalBinaryTypeOp) and then transition to type.sml
     for their type-term-specific parts (groundMatchesGeneric and
     findSpecialConversion)

   * the nullability system is more spread out, covering some part
     of the type normalizer in type.sml and some part of the property
     allocation scheme in eval.sml

I'm sad to hear that the RI was not sufficiently clear on these points, 
but I guess this was a risk in the choice of language; SML is terse but 
also not always familiar.

Some of the SML code can be "lowered", via a prototype converter I have 
written, to english. Notational details are erased but the names and 
structure is preserved. Would this be useful? Another possibility is to 
expand the internal commentary of the RI, or write some sort of  study 
guide.

I'm hesitant to commit to "yet another bit of plain english docs", both 
because everyone who could write them already has lots to do, and 
because there is nothing guaranteeing that such docs remain current or 
honest. As we've seen, it's easy for an english doc -- such as a wiki 
page -- to drift into obsolescence if there's not constant energy spent 
updating it.

-Graydon



More information about the Es4-discuss mailing list