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
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
